On Fri, 26 Mar 2010, Andrea Arcangeli wrote: > BTW, unfortunately according to tons of measurements done so far, SLUB > is too slow on most workstations and small/mid servers (usually single > digits but in some case even double digits percentage slowdowns > depending on the workload, hackbench tends to stress it the > most). It's a tradeoff between avoiding wasting tons of ram on > 1024-way and running fast. Either that or something's wrong with SLUB > implementation (and I'm talking about 2.6.32, no earlier code). I'd > also like to save memory so it'd be great if SLUB can be fixed to > perform faster! The SLUB fastpath is the fastest there is. Problems arise because of locality constraints in SLUB. SLAB can throw gobs of memory at it to guarantee a high cache hit rate but to cover all angles on NUMA requires to throw the gobs multiple times. The weakness is SLUBs free functions which frees the object directly to the slab page instead of running through a series of caching structures. If frees occur to locally dispersed objects then SLUB is at a disadvantage since its hitting cold cache lines for metadata on free. On the other hand SLUB hands out objects in a locality aware fashion and not randomly from everywhere like SLAB. This is certainly good to reduce TLB pressure. Huge pages would accellerate SLUB since more objects can be served from the same page than before. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>