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

[Curt Sampson <cjs@example.com>]

On 2008-11-06 16:30 +0900 (Thu), Stephen J. Turnbull wrote:

> If "affinity" is being used as a concrete noun rather than a
> relationship, so much the worse for Pfister and his/her followers, who
> should take a remedial course in English usage.

Probably my bad. I don't have the book in front of me.

> Otherwise, I think you're confusing a general definition of the term
> with a particular implementation that you like, and are harassing
> Linux for having a different implementation.

Well, that doesn't make sense, given that Linux *does* have a good
implementation of CPU affinity, as well as being able to do CPU binding,
which they also confusingly call affinity.

> In particular, Linux apparently implements "preference" in a
> particularly simple way: either a CPU is "preferred" or it is
> *prohibited*, and all preferred CPUs have (implicitly) equal affinity
> for the process.

That style of not-blowing-out-CPU-caches was what people used before
developing nice CPU affinity algorithms, which do the same thing, but
without getting stuck in situations where you have plenty of free CPU
cycles but all the bound processes are stuck sharing a busy CPU.

On 2008-11-06 16:58 +0900 (Thu), Edward Middleton wrote:

> http://www.linuxjournal.com/article/6799

Cute the distinguishing between "hard" and "soft" affinity, but especially
how they explain it:

    If a processor is bound to CPU zero, for example, then it can run
    only on CPU zero.

Why not just call it binding then, and not trample on the term
"affinity" which has a different, and in some senses opposite meaning,
from what they're talking about?

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com