On Wed, 26 May 2010, Nick Piggin wrote: > > The initial test that showed the improvements was on IA64 (16K page size) > > and that was the measurement that was accepted for the initial merge. Mel > > was able to verify those numbers. > > And there is nothing to prevent a SLAB type allocator from using higher > order allocations, except for the fact that it usually wouldn't because > far more often than not it is a bad idea. 16K is the base page size on IA64. Higher order allocations are a pressing issue for the kernel given growing memory sizes and we are slowly but surely making progress with defrag etc. > > Fundamentally it is still the case that memory sizes are increasing and > > that management overhead of 4K pages will therefore increasingly become an > > issue. Support for larger page sizes and huge pages is critical for all > > kernel components to compete in the future. > > Numbers haven't really shown that SLUB is better because of higher order > allocations. Besides, as I said, higher order allocations can be used > by others. Boot with huge page support (slub_min_order=9) and you will see a performance increase on many loads. > Also, there were no numbers or test cases, simply handwaving. I don't > disagree it might be a problem, but the way to solve problems is to > provide a test case or numbers. 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). > Given that information, how can you still say that SLUB+more big changes > is the right way to proceed? Have you looked at the SLAB code? Also please stop exaggerating. There are no immediate plans to replace SLAB. We are exploring a possible solution. If the SLEB idea pans out and we can replicate SLAB (and SLUB) performance then we will have to think about replacing SLAB / SLUB at some point. So far this is just a riggedy thing that barely works where there is some hope that the SLAB - SLUB conumdrum may be solved by the approach. -- 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>