Re: [tlug] Re: [RFC] Outline of the fast HTTP talk (PHP benchmark)

[Edward Middleton <emiddleton@example.com>]

Curt Sampson wrote:
> On 2008-11-06 11:45 +0900 (Thu), Stephen J. Turnbull wrote:
>
>   
>> Curt Sampson writes:
>>
>>  > To use it otherwise is a confusing misuse of the term. [Insert rant
>>  > about Linux folks changing common terminology here.]
>>
>> Er, what usage do Linux folks use it for?
>>     
>
> According to the schedtool manpage:
>
>     AFFINITY MASK
>        The affinity-argument determines on which CPUs a process is
>        allowed to run. It consists of a simple bitmask represented in
>        hexadecimal.  CPU0 is denoted by the least-significant bit,
>        CPU1 by the second  least-significant and so on.
>
> In normal MP usage (e.g., according to Pfister's _In Search of
> Clusters_) the affinity is the CPU on which it would be preferred to
> give a particular process its next quantum. But if you've got two
> CPU-intensive processes running on CPU0, and CPU1 is relatively free, a
> scheduler using CPU affinity would move one of the processes from CPU0
> to CPU1, and probably change its affinity as well (though perhaps not,
> if it were a NUMA architecture).
>   

Which would seem to be consistent with Linux's implementation.  Unless
it mentions *affinity mask* somewhere in Pfister's _In Search of
Clusters_ .  The point of the *affinity mask* is to force the kernel to
avoid switching the process even in the above case.

Edward