On Thu, May 27, 2010 at 09:24:28AM -0500, Christoph Lameter wrote: > On Wed, 26 May 2010, Nick Piggin wrote: > > > > > > The reason that the alien caches made it into SLAB were performance > > > > > numbers that showed that the design "must" be this way. I prefer a clear > > > > > maintainable design over some numbers (that invariably show the bias of > > > > > the tester for certain loads). > > > > > > > > I don't really agree. There are a number of other possible ways to > > > > improve it, including fewer remote freeing queues. > > > > > > You disagree with the history of the allocator? > > > > I don't agree with you saying that it "must" be that way. There are > > other ways to improve things there. > > People told me that it "must" be this way. Could not convince them > otherwise at the time. So again there was no numbers just handwaving? > I never wanted it to be that way and have been > looking for other ways ever since. SLUB is a result of trying something > different. > > > then we can go ahead and throw out SLUB and make incremental > > improvements from there instead. > > I am just amazed at the tosses and turns by you. Didnt you write SLQB on > the basis of SLUB? And then it was abandoned? If you really believe ths Sure I hoped it would be able to conclusively beat SLAB, and I'd thought it might be a good idea. I stopped pushing it because I realized that incremental improvements to SLAB would likely be a far better idea. > and want to get this done then please invest some time in SLAB to get it > cleaned up. I have some doubt that you are aware of the difficulties that > you will encounter. I am working on it. We'll see. -- 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>