The machdep.hyperthreading_allowed & ULE weirdness in 7.1

Maxim Sobolev sobomax at FreeBSD.org
Mon Feb 23 12:17:48 PST 2009


Robert Watson wrote:
> 
> 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.

So, are you suggesting that we should disable 
machdep.hyperthreading_allowed with ULE in 7.x and current to avoid 
confusion?

-Maxim


More information about the freebsd-current mailing list