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