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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
