cpuset and affinity implementation

[Jeff Roberson]

On Tue, 26 Feb 2008, Daniel Eischen wrote:

> On Mon, 25 Feb 2008, Jeff Roberson wrote:
>
>> Binding a processor set to the process simply sets the per-thread binding 
>> of each thread in the process.  There is otherwise no specific process 
>> binding. We could keep a pointer to the last specifically bound set in the 
>> process if we wanted, but what would it be used for other than querying the 
>> id of the process?  What if each thread was seperately specifically bound 
>> to a different set?  What set should be used on fork? The set of the 
>> process or the thread that called fork?  What about when creating a new 
>> thread?
>
> The set used on fork should be the set of the calling thread,
> same concept as signal masks I would think.  Same thing when
> creating a new thread.  I guess I'd check how Linux and Solaris
> do it, see if they are consistent.

Yes, that's what I do now.  The mask is inherited from the creater. 
I was just pointing out that it gets a little ambiguous if we were to have 
some notion of a per-process set.

>
> I can see how you might _not_ want to inherit bindings in a
> created thread.  For a process with real-time threads, the
> application might start with superuser privileges, create some
> threads with real-time priority and set their bindings, then
> setuid() to remove superuser privileges.  Is a privilege check
> made in a newly created thread when applying inherited bindings?

No privilege check on fork.  This would create weird failure modes.

>
>> See above discussion.  I'm not sure what you mean by 'default' cpuset here.
>
> I imagine the 'default' cpuset as the system's default cpuset,
> in lieu of any administratively created cpusets and bindings
> for the process (inherited or explicit).

My opinion is that if we decide that it's important to assign numbered 
sets to tids we need then to allow cpuset_getid to return multiple ids for 
WHICH_PID.

Jeff

>
> -- 
> DE
>