[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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |