getaffinity/setaffinity and cpu sets.

[Jeff Roberson]

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
>