On Wed, May 26, 2010 at 12:34:09AM +1000, Nick Piggin wrote: > On Tue, May 25, 2010 at 09:13:37AM -0500, Christoph Lameter wrote: > > The queues sacrifice a lot there. The linked list does not allow managing > > cache cold objects like SLAB does because you always need to touch the > > object and this will cause regressions against SLAB. I think this is also > > one of the weaknesses of SLQB. > > But this is just more handwaving. That's what got us into this situation > we are in now. > > What we know is that SLAB is still used by all high performance > enterprise distros (and google). And it is used by Altixes in production > as well as all other large NUMA machines that Linux runs on. > > Given that information, how can you still say that SLUB+more big changes > is the right way to proceed? Might I add that once SLAB code is cleaned up, you can always propose improvements from SLUB or any other ideas for it which we can carefully test and merge in slowly as bisectable changes to our benchmark performance slab allocator. In fact, if you have better ideas in SLEB, I would encourage it. -- 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>