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>