Re: SMP Process to CPU locking

From: Will Deutsch (wdeutsch@netapp.com)
Date: Sat Mar 25 2000 - 05:45:11 EST


On Sat, 25 Mar 2000 02:26:14 Paul Witta wrote:
>
...
> otoh, if you compare common i386 hardware to eg sun, where affinity
> binding is common, you ll see that in i386 the memory is at the same
> "distance" to every processor, while on sun, every processor has it s own
> ram on the same sbus card. there it makes sense to bind the processor to
> the app on it s "local" ram.
>
> IMO this corresponds to hardware architecutre which is very uncommon on
> i386, chrp ppc, alpha, s/390 and so on -- this might be important on sun
> 3000, 6000, 10000 servers as well as on some hp pa risc machines...

Sun systems don't have NUMA architechture. Just like ix86, ppc, alpha,
and so on they use a unified memory system.

OTOH: All processors have some level of cache that is theirs alone. Both
x86 and Sparc do this... Intel has L1 and L2 cache and... so does Sun.
Processor affinity is in general just a good Idea to minimize cache
coherincy traffic on the system bus.

Here is an example... vi(p1) is running on P1. It's quanta expires and
df(p2) if now on P1. P2 has been running troff(p3) this whole time. At
this instant (time t) both processors are up for scheduling: df didn't
purge all the cache on P1 so vi is still stored in the L1 and L2 for
that processor. If vi goes to P2 P1 had to flush the pages back to
memory and P2 has to load them. If vi goes to P1 none of that happens...

I hope that clears it up....

-cheers,
Will

Sustaining Jedi

This email is sent in loving memory of:
Johnny Grasso
        &
Ronald Farber

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:15 EST