Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1

On Mon, 23 Feb 2009, Maxim Sobolev wrote:

> Robert Watson wrote:
>> In the mean time, it sounds like the sysctl does need to be reimplemented 
>> or removed, but one question is how far to take it -- caches are shared to 
>> varying degrees at varying levels of the topology.  However, I believe the 
>> recommendation has generally moved to disabling hyperthreading using the 
>> BIOS, as that uses the vendor's notion of hyperthreading.  The idea of 
>> changing the setting at run-time is currently untenable because we don't 
>> have the OS infrastructure to take CPUs out of service, although growing it 
>> would be useful in order to support virtual machine dynamic CPU 
>> reconfiguration.
>
> Well, as far as I know, what SCHED_4BSD does is simply stopping scheduling 
> threads to the logical core(s). One doesn't need infrastructure to take CPU 
> off-line for doing the same in SCHED_ULE.
>
> Unfortunately access to BIOS is not always an option and also some BIOSes 
> don't even provide a feature to turn HTT off.

It's not quite that simple -- in a world of device drivers pinning threads to 
CPUs for workload distribution, callout threads and sched_bind()/sched_pin() 
for crypto load distribution, etc, you need a whole infrastructure for 
software-disabled CPUs.  Disabling it using the BIOS or device.hints is the 
only reliable way to do this right now.  Changing the architecture of the 
kernel to disable CPU cores after boot is a significant investment of work, 
and as I mentioned elsewhere, it is disable to do this so that we can support 
dynamic reconfiguration in the presence of a hypervisor, but it's highly 
non-trivial.  There may be some shortcuts that can be taken for policy reasons 
in the probing of CPUs when the topology is detected that avoid the full 
dynamic solution having to be done in the short-term, that in effect are a 
short-hand for device.hints entries, but I don't know to what extent the CPU 
topology from ACPI is available at the point where we'd need to know that.

Robert N M Watson
Computer Laboratory
University of Cambridge