Christoph Lameter <cl@xxxxxxxxx> writes: Not looked at code so far, but just comments based on the description. But thanks for working on this, it's good to have alternatives to the ugly slab.c > V3->V4: > - Lots of debugging > - Performance optimizations (more would be good)... > - Drop per slab locking in favor of per node locking for > partial lists (queuing implies freeing large amounts of objects > to per node lists of slab). Is that really a good idea? Nodes (= sockets) are getting larger and larger and they are quite substantial SMPs by themselves now. On Xeon 75xx you have 16 virtual CPUs per node. > 1. SLUB accurately tracks cpu caches instead of assuming that there > is only a single cpu cache per node or system. > > 2. SLUB object expiration is tied into the page reclaim logic. There > is no periodic cache expiration. Hmm, but that means that you could fill a lot of memory with caches before they get pruned right? Is there another limit too? -Andi -- ak@xxxxxxxxxxxxxxx -- Speaking for myself only. -- 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>