getaffinity/setaffinity and cpu sets.

[Daniel Eischen]

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