getaffinity/setaffinity and cpu sets.

[Jeff Roberson]

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.

Thanks,
Jeff

>
> Ceri
> -- 
> That must be wonderful!  I don't understand it at all.
>                                                  -- Moliere
>