Date: Fri, 22 Feb 2008 17:44:24 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> 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: <Pine.GSO.4.64.0802221739230.19608@sea.ntplx.net> In-Reply-To: <20080222121253.N920@desktop> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0802221739230.19608>