Date: Fri, 22 Feb 2008 13:10:00 -1000 (HST) From: Jeff Roberson <jroberson@chesapeake.net> To: Daniel Eischen <deischen@freebsd.org> Cc: arch@freebsd.org, Robert Watson <rwatson@freebsd.org>, David Xu <davidxu@freebsd.org>, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: getaffinity/setaffinity and cpu sets. Message-ID: <20080222130701.U920@desktop> In-Reply-To: <Pine.GSO.4.64.0802221739230.19608@sea.ntplx.net> References: <20071219211025.T899@desktop> <18311.49715.457070.397815@grasshopper.cs.duke.edu> <20080112182948.F36731@fledge.watson.org> <20080112170831.A957@desktop> <Pine.GSO.4.64.0801122240510.15683@sea.ntplx.net> <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> <Pine.GSO.4.64.0802221739230.19608@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080222130701.U920>