Re: cpuset and affinity implementation


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

_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"