Date: Mon, 23 Feb 2009 12:17:26 -0800 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Robert Watson <rwatson@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: <49A30456.5010400@FreeBSD.org> In-Reply-To: <alpine.BSF.2.00.0902231853040.92010@fledge.watson.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> <alpine.BSF.2.00.0902231853040.92010@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49A30456.5010400>