Messages in this thread | | | Date | Thu, 10 Jan 2008 11:24:12 -0800 (PST) | From | Christoph Lameter <> | Subject | Re: [RFC PATCH] greatly reduce SLOB external fragmentation |
| |
On Thu, 10 Jan 2008, Matt Mackall wrote:
> One idea I've been kicking around is pushing the boundary for the buddy > allocator back a bit (to 64k, say) and using SL*B under that. The page > allocators would call into buddy for larger than 64k (rare!) and SL*B > otherwise. This would let us greatly improve our handling of things like > task structs and skbs and possibly also things like 8k stacks and jumbo > frames. As SL*B would never be competing with the page allocator for > contiguous pages (the buddy allocator's granularity would be 64k), I > don't think this would exacerbate the page-level fragmentation issues.
This would create another large page size (and that would have my enthusiastic support). It would decrease listlock effect drastically for SLUB. Even the initial simplistic implementation of SLUB was superior on the database transaction tests (I think it was up ~1%) on IA64 from the get go. Likely due to the larger 16k page size there. The larger page size could also be used for the page cache (ducking and running.....)? A 64k page size that could be allocated without zone locks would be very good for SLUB.
However, isnt this is basically confessing that the page allocator is not efficient for 4k page allocations? I have seen some weaknesses there. The overhead in the allocation path in particular is bad and I was thinking about applying the same ideas used in SLUB also to the page allocator in order to bring the cycle count down from 500-1000 to 60 or so. Since both SLUB and SLOB use the page allocator for allocs >PAGE_SIZE this would not only benefit the general kernel but also the slab allocations.
| |