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
_______________________________________________
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"
