On Fri, Mar 26, 2010 at 01:00:12PM -0500, Christoph Lameter wrote: > On Fri, 26 Mar 2010, Andrea Arcangeli wrote: > > > 2) writing a HPAGE_PMD_ORDER front slab allocator. I don't think memory > > compaction is capable of relocating slab entries in-use (correct me if I'm > > wrong, I think it's impossible as long as the slab entries are mapped by 2M > > SLUB is capable of using huge pages. Specify slub_min_order=9 on boot and > it will make the kernel use huge pages. > > > pages and not 4k ptes like vmalloc). So the idea is that we should have the > > slab allocate 2M if it fails, 1M if it fails 512k etc... until it fallbacks > > to 4k. Otherwise the slab will fragment the memory badly by allocating with > > alloc_page(). Basically the buddy allocator will guarantee the slab will > > generate as much fragement as possible because it does its best to keep the > > high order pages for who asks for them. Probably the fallback should > > Fallback is another issue. SLUB can handle various orders of pages in the > same slab cache and already implements fallback to order 0. To implement > a scheme as you suggest here would not require any changes to data > structures but only to the slab allocation functions. See allocate_slab() > in mm/slub.c Thanks for the information! Luckily it seems Mel already taken care of this part in his patchset. But in my view, this feature should be available outside of SLUB/SLAB and potentially available to drivers and such. SLUB having this embedded is nice to know!!! BTW, unfortunately according to tons of measurements done so far, SLUB is too slow on most workstations and small/mid servers (usually single digits but in some case even double digits percentage slowdowns depending on the workload, hackbench tends to stress it the most). It's a tradeoff between avoiding wasting tons of ram on 1024-way and running fast. Either that or something's wrong with SLUB implementation (and I'm talking about 2.6.32, no earlier code). I'd also like to save memory so it'd be great if SLUB can be fixed to perform faster! -- 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>