Hi,

I had to deal with this issue with perfmon back in 2.6.30 and earlier kernels.
I remember that I was surprised not to find any easy helper function to figure
this out back then. Being HT capable is different from having HT enabled.
Seems like the situation has not improved since then.

My solution at the time (2.6.30) was to do:
        ht_enabled = cpumask_weight(__get_cpu_var(cpu_sibling_map)) > 1;

Not too convinced the per-cpu variable is necessary because I don't
know of a BIOS that would allow you to turn on HT on only some of the
cores (AFAIK, this is an all or nothing feature).


On Tue, Jan 4, 2011 at 12:10 PM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
quoted text
> On Mon, 2011-01-03 at 11:53 -0800, H. Peter Anvin wrote:
>> On 01/03/2011 02:58 AM, Peter Zijlstra wrote:
>> >>
>> >> This function can be simplified as below,
>> >>
>> >> static bool ht_enabled()
>> >> {
>> >>         if (!cpu_has(&boot_cpu_data, X86_FEATURE_HT))
>> >>                 return false;
>> >>
>> >>         return smp_num_siblings > 1;
>> >> }
>> >>
>> >> But this still can't detect if HT is on or off.
>> >> smp_num_siblings is always 2 even if HT is disabled in BIOS.
>> >>
>> >> Any idea how to detect if HT is on or not?
>> >
>> > Not quite sure, the intel docs aren't really clear on how the HW
>> > supports HT, has 2 siblings but BIOS disabled it thing works. I just
>> > tried reading the arch/x86 code but that only got me more confused.
>> >
>> > hpa, could you comment?
>> >
>>
>> Zeroeth of all: anyone who writes () in a function prototype in C needs
>> to get severely napalmed, maimed, hung and then really hurt.  It is
>> (void) in C, () means (...) which is literally NEVER what you want.
>>
>> Now, *first* of all: smp_num_siblings as it sits is obviously broken;
>> the whole notion of a global variable for what is inherently a per-cpu
>> property is just braindead.  At least theoretically there could be cores
>> with and without HT or with different thread count in the same system.
>>
>> Second, perf should get this from /proc/cpuinfo, not by grotting around
>> cpuid by itself.
>
> Its the kernel space bit that wants to know if HT is enabled on CPU
> bringup, /proc/cpuinfo is kinda useless in that context.
>
>> Third, the code in the kernel is indeed pretty confusing, and it also
>> has the global variable braindamage... but either it works (in which
>> case getting the data from /proc/cpuinfo works) or it needs fixing in
>> addition to the global variable issue.
>
> So you failed to address the primary question, how do we tell if HT is
> enabled for a particular CPU?
>
> X86_FEATURE_HT tells us the CPU supports telling us about HT,
> smp_num_siblings > 1 tells us the CPU is capable of HT. But Lin found
> that if you disable HT in the BIOS both those are true but we still
> don't have HT enabled.
>
> The problem we have to address is that Intel has some MSRs shared
> between threads and if HT is enabled we need to allocate some memory to
> manage this shared resource.
>
> The simple check outlined above X86_FEATURE_HT && smp_num_siblings > 1,
> will get us most of the way and will I think be good enough (false
> positives but no false negatives). But it did get us wondering about how
> all this works.
>
> So could you, irrespective of Linux implementation details tell us how
> to detect if HT is available and enabled from a HW and BIOS perspective?
>
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/