Re: [RFC PATCH] greatly reduce SLOB external fragmentation

From: Christoph Lameter
Date: Thu Jan 10 2008 - 14:24:32 EST


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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/