From owner-freebsd-arch@FreeBSD.ORG Fri Feb 22 23:08:44 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 3EDF316A402; Fri, 22 Feb 2008 23:08:44 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 1BCC813C45E; Fri, 22 Feb 2008 23:08:44 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id m1MN8ebp002439; Fri, 22 Feb 2008 18:08:41 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Fri, 22 Feb 2008 13:10:00 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Daniel Eischen In-Reply-To: Message-ID: <20080222130701.U920@desktop> 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 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 23:08:44 -0000 On Fri, 22 Feb 2008, Daniel Eischen wrote: > 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()... In the solaris model sets are explicitly created and destroyed. In my model they are transient and only exist as long as they have members. So I don't have a destroy. fwiw it looks like linux also does a persistent thing that you modify via a filesystem. If we later want to add some attributes which we'd like to persist it'd be as simple as adding a destroy call and adding an extra ref on create. We should decide that before 8.0 however when the api becomes more entrenched. > > -- > DE >