Messages in this thread | | | Date | Sat, 25 Mar 2000 02:45:11 -0800 | From | Will Deutsch <> | Subject | Re: SMP Process to CPU locking |
| |
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/
| |