Date: Mon, 23 Feb 2009 18:56:27 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Maxim Sobolev <sobomax@FreeBSD.org> Cc: Frank Behrens <frank@ilse.behrens.de>, Jeff Roberson <jeff@FreeBSD.org>, "current@freebsd.org" <current@FreeBSD.org>, stable@FreeBSD.org Subject: Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 Message-ID: <alpine.BSF.2.00.0902231853040.92010@fledge.watson.org> In-Reply-To: <49A2ED6A.9040202@FreeBSD.org> References: <alpine.BSF.2.00.0902231000300.98609@fledge.watson.org> <200902231652.n1NGqMxH047731@post.behrens.de> <49A2DE9D.4090902@FreeBSD.org> <alpine.BSF.2.00.0902231801450.92010@fledge.watson.org> <49A2ED6A.9040202@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.0902231853040.92010>