From: Christoph Lameter To: Pekka Enberg Cc: Mel Gorman Cc: linux-mm@kvack.org Subject: SLUB: Variable order slab support Subject-Prefix: [patch @num@/@total@] Pekka brought up the idea of supporting arbitrary orders of pages per slab a few days ago. Initially I thought this was not doable but then I realized that there is only a single case where we actually need the max count of objects per slab halfway in the slowpath. Otherwise we are already getting by through pointer checks because access to the kmem_cache fields is usually a cache miss from the hotpaths. And the check can be made very efficient by putting the number of objects in the mapcount of the second page struct if its a compound page. So we likely wont need access to another cacheline. The patchset here implements Pekka's idea with one simplification: Any failure of a higher order alloc leads to an order 0 alloc to satisfy the request. I thought falling back in a loop order by order would likely be inefficient. It would be nice if the page allocator would support something like: I want a page sized Y but I am going to take anything smaller too. Then we could get where Pekka wanted to go. Performance gain is around 1% on netbench. Puts a lot of higher order alloc stress on the page allocator. Not sure what effect this will have on page allocator allocation speed if the system is running mixed loads. On the other hand: The fallback finally allows one to tune slubs performance in the same way as slab. The allocation order field in /sys/kernel/slab//order becomes writable. So one can tune the allocation size in a way comparable to the queue size in the slab allocator. The specification of slub_min_objects has now a reasonable effect. Specifying slub_min_objects=4 yields a similar slab order setup as 2.6.24. But the defaults are now set to min_objects=60 and max_order=6 (256k). I will be out of town until the 27th of February (Somewhere off the grid in Northern California, spotty cell phone coverage).