This is a discussion on Re: getaffinity/setaffinity and cpu sets. - FreeBSD ; On Thu, 21 Feb 2008, Ceri Davies wrote: > On Thu, Feb 21, 2008 at 09:27:41AM +0000, Robert Watson wrote: > >> - You don't mention what happens if a process's cpu set changes to preclude a >> CPU the ...
On Thu, 21 Feb 2008, Ceri Davies wrote:
> On Thu, Feb 21, 2008 at 09:27:41AM +0000, Robert Watson wrote:
>> - You don't mention what happens if a process's cpu set changes to preclude a
>> CPU the process has a thread with affinity for. Online, you suggested
>> SIGKILL, and I thought maybe a new SIGCPUGONE with a default SIGKILL action
>> might be a friendlier model. We should see what Solaris and others do here
>> though. I like the idea that the affinity is a guarantee in userspace
>> because it means that you can rely on it; I'm OK with the idea that your
>> thread always runs on the CPUs you have affinity for unless in the
>> SIGCPUGONE handler :-).
> If a processor set disappears from under a process on Solaris, the
> process gets moved to the "default" set (or, in other words, they aren't
> in a set any more).
Yes, that's ok, but what if the process has requested a specific cpu that
it's now no longer allowed to access? The sets are seperate from the
thread's specific requested binding. If the thread binds to a specific
processor within the set and the set disappears what should we do? What
if that process was relying on the binding to access cpu specific features
such as tsc? Allowing it to migrate could then break the code.
> That must be wonderful! I don't understand it at all.
> -- Moliere
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"