From owner-freebsd-current@FreeBSD.ORG Mon Feb 23 18:56:31 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5865B1065BCE; Mon, 23 Feb 2009 18:56:31 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD2F8FC1D; Mon, 23 Feb 2009 18:56:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 1F2CD46B23; Mon, 23 Feb 2009 13:56:27 -0500 (EST) Date: Mon, 23 Feb 2009 18:56:27 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Maxim Sobolev In-Reply-To: <49A2ED6A.9040202@FreeBSD.org> Message-ID: References: <200902231652.n1NGqMxH047731@post.behrens.de> <49A2DE9D.4090902@FreeBSD.org> <49A2ED6A.9040202@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Frank Behrens , Jeff Roberson , "current@freebsd.org" , stable@FreeBSD.org Subject: Re: The machdep.hyperthreading_allowed & ULE weirdness in 7.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 18:56:37 -0000 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