From owner-freebsd-arch@FreeBSD.ORG Fri Feb 22 22:44:34 2008 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 3562216A402; Fri, 22 Feb 2008 22:44:34 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id EAC9313C45A; Fri, 22 Feb 2008 22:44:33 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.2/8.14.2/NETPLEX) with ESMTP id m1MMiOns010827; Fri, 22 Feb 2008 17:44:23 -0500 (EST) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.0 (mail.netplex.net [204.213.176.10]); Fri, 22 Feb 2008 17:44:24 -0500 (EST) Date: Fri, 22 Feb 2008 17:44:24 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Jeff Roberson In-Reply-To: <20080222121253.N920@desktop> Message-ID: References: <20071219211025.T899@desktop> <18311.49715.457070.397815@grasshopper.cs.duke.edu> <20080112182948.F36731@fledge.watson.org> <20080112170831.A957@desktop> <20080112194521.I957@desktop> <20080219234101.D920@desktop> <20080220101348.D44565@fledge.watson.org> <20080220005030.Y920@desktop> <20080220105333.G44565@fledge.watson.org> <47BCEFDB.5040207@freebsd.org> <20080220175532.Q920@desktop> <20080220213253.A920@desktop> <20080221092011.J52922@fledge.watson.org> <20080222121253.N920@desktop> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Robert Watson , David Xu , Andrew Gallatin Subject: Re: getaffinity/setaffinity and cpu sets. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 22:44:34 -0000 On Fri, 22 Feb 2008, Jeff Roberson wrote: > > On Thu, 21 Feb 2008, Robert Watson wrote: > >> On Wed, 20 Feb 2008, Jeff Roberson wrote: >> >>> I also have a 'cpuset' command which can run a new program with a given >>> cpu set, view and modify sets of arbitrary pids. This is all working and >>> I can supply patches if anyone is interested. I have to implement 4BSD >>> support before I can commit. >>> >>> I have a proposal for solaris style processor sets which I think is simple >>> and sufficient for most cases. It involves the following new syscalls: >>> >>> int cpuset(void); int setcpuset(pid_t pid, int setid); int getcpuset(pid_t >>> pid); >>> >>> The notion would be that you can create a new numbered cpuset with >>> cpuset(). You can modify or inspect its affinity with get/setaffinity >>> above and the CPU_WHICH_SET argument. The cpuset exists as long as there >>> are members of the set. Sort of like a process group or session. The >>> {get,set}cpuset calls can inspect or modify the state. >>> >>> This set would not be modifiable by user processes or by processes in a >>> jail. It would create the restriction that differs between 'avail' and >>> 'sys' above. Processors would be able to directly bind to any processor >>> within the set. Changing the set would apply to all processes in the set. >>> The cpuset would be per-process while the mask is per-thread. Sets >>> involvement is inherited on fork(). >>> >>> In solaris sets can be named and have a more complete management api. I'm >>> not really interested in implementing all of that but I believe what I >>> have outlined here would be subset of this and no code/syscalls would be >>> wasted. >>> >>> Comments? Objections? I'm fairly pleased with this arrangement now. >> >> Just to put a few notes from our conversation on IRC in e-mail: >> >> - I think I'd prefer int cpuset(cpuset_t *set), int getcpuset(pid_t, >> cpuset_t >> *) so that we don't mix up ID's and return values. More recent interfaces >> tend to do this, I believe, and it means that the prototype, even if not >> the >> ABI, remains the same if the set identifier changes in the future. > > Ok, this is a good suggestion and I did this. This is actually my preferred > method as well but most syscalls don't follow this pattern and I was trying > to make it look syscallish. I would probably use cpuset_create(), cpuset_get(), cpuset_set()... Don't know if you need cpuset_destroy()... -- DE