From owner-freebsd-arch@FreeBSD.ORG Thu Dec 20 11:10:59 2007 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C20F116A417 for ; Thu, 20 Dec 2007 11:10:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 362EA13C448 for ; Thu, 20 Dec 2007 11:10:58 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 30694 invoked from network); 20 Dec 2007 10:38:46 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 20 Dec 2007 10:38:46 -0000 Message-ID: <476A4DCC.4040206@freebsd.org> Date: Thu, 20 Dec 2007 12:11:08 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: Jeff Roberson References: <20071219211025.T899@desktop> In-Reply-To: <20071219211025.T899@desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org Subject: Re: Linux compatible setaffinity. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2007 11:10:59 -0000 Jeff Roberson wrote: > I have implemented a linux compatible sched_setaffinity() call which is > somewhat crippled. This allows a userspace process to supply a bitmask > of processors which it will run on. I have copied the linux interface > such that it should be api compatible because I believe it is a sensible > interface and they beat us to it by 3 years. The Linux (and Solaris) style setaffinity is rather low level and any user of it has to make many assumptions based on incomplete knowledge of the underlying hardware and its architecture (buses, caches, latency between cores, etc). In practical use I'd rather have a function to bind myself to the current CPU or CPU number X, and then to specify that new threads or forked processes should emerge on another, but not this CPU. Pepper that with a few hints like latency and cache affinity (important or not important) the kernel can act on appropriately and it becomes much more powerful and simpler to use. Taking it even further an application may want to specify that it would like to run on a number X of cores that are close (latency/cache) together, be permanently bound to it and to repel any other such requests. This way I can run my database server on socket 1 cores 1-4, and the webserver on socket 2 cores 5-8 more or less automagically. sched_setaffinity requires a lot of operator involvement and architecture knowledge to make that happen. Not that I'm against a Linux compatible sched_setaffinity(), it's just not as practical to use as other constructs. Food for thought. -- Andre