* Pekka Enberg <penberg@cs.helsinki.fi> wrote:Yes, you can find gigs tied up on systems that have 100 GB of RAM, or you can have gigs tied up if you over-size your caches. I'd like to see an accurate calculation done on this. yes, it's what i referred to as "distributed, per node cache". It has no "quadratic overhead". It has SLAB memory spread out amongst nodes. I.e. 1 million pages are distributed amongst 1k nodes with 1000 pages per node with each node having 1 page. But that memory is not lost and it's disingenous to call it 'overhead' and it very much comes handy for performance _IF_ there's global workload that involves cross-node allocations. It's simply a cache that is mis-sized and mis-constructed on large node count systems but i bet it makes quite a performance difference on low-node-count systems. On high node-count systems it might make sense to reduce the amount of cross-node caching and to _structure_ the distributed NUMA SLAB cache in an intelligent way (perhaps along cpuset boundaries) - but a total, design level _elimination_ of this caching concept, using very misleading arguments, just looks stupid to me ... Ingo --
| KOSAKI Motohiro | [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| Nick Piggin | [patch 3/6] mm: fix fault vs invalidate race for linear mappings |
| Stefan Richter | Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures |
| Ingo Molnar | [bug] stuck localhost TCP connections, v2.6.26-rc3+ |
git: | |
| Peter Zijlstra | Re: [PATCH 3/3] Convert the UDP hash lock to RCU |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: 2.6.25-rc8: FTP transfer errors |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Doug Evans | Re: Stabilizing Linux |
| Robert Blum | And another version of the INFO sheet |
| Marc CORSINI | find-1.2 (binaries only) |
| Yanek Martinson | Re: Porting g++ 1.40.3 |
