From owner-freebsd-stable@FreeBSD.ORG Mon Feb 23 20:17:47 2009 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 433FD1065674; Mon, 23 Feb 2009 20:17:47 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id DE60F8FC22; Mon, 23 Feb 2009 20:17:46 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n1NKHhhj015083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Feb 2009 12:17:44 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <49A30456.5010400@FreeBSD.org> Date: Mon, 23 Feb 2009 12:17:26 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Robert Watson References: <200902231652.n1NGqMxH047731@post.behrens.de> <49A2DE9D.4090902@FreeBSD.org> <49A2ED6A.9040202@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2009 20:17:48 -0000 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