On Tue, 8 Sep 2015, Jesper Dangaard Brouer wrote: > This test was a single CPU benchmark with no congestion or concurrency. > But the code was compiled with CONFIG_NUMA=y. > > I don't know the slAb code very well, but the kmem_cache_node->list_lock > looks like a scalability issue. I guess that is what you are referring > to ;-) That lock can be mitigated like in SLUB by increasing per cpu resources. The problem in SLAB is the categorization of objects on free as to which node they came from and the use of arrays of pointers to avoid freeing the object to the object tracking metadata structures in the slab page. The arrays of pointers have to be replicated for each node, each slab and each processor. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>