[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 6/8] x86: (command line option to) avoid use of secondary hyper-threads

>>> On 16.07.18 at 14:37, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 13/07/18 09:13, Jan Beulich wrote:
>>>>> On 12.07.18 at 17:45, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 11/07/18 13:10, Jan Beulich wrote:
>>>> --- a/docs/misc/xen-command-line.markdown
>>>> +++ b/docs/misc/xen-command-line.markdown
>>>> @@ -1040,6 +1040,13 @@ identical to the boot CPU will be parked
>>>>  ### hpetbroadcast (x86)
>>>>  > `= <boolean>`
>>>> +### ht (x86)
>>> I'd suggest smt rather than ht here.  SMT is the technical term, while
>>> HT is Intel's marketing name.
>> Hmm, many BIOSes (if the have such an option) talk about HT, which
>> to me makes "ht" a closer match. How about we allow both?
> That's because a BIOS is custom to the hardware it runs on.
> Have you tried setting up an alias before? (given the specific
> deficiency of the *_param() infrastructure in this area)  I'm don't
> think an alias is worth the effort.

This reads as if you were expecting problems. Instead of

+int8_t __read_mostly opt_ht = -1;
+boolean_param("ht", opt_ht);

what we'd have is simply

+int8_t __read_mostly opt_ht = -1;
+boolean_param("ht", opt_ht);
+boolean_param("smt", opt_ht);

(and whether we use opt_ht or opt_smt doesn't matter much
to me). I don't see any source of possible issues with this.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.