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 -- 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>