Re: [RFC PATCH] greatly reduce SLOB external fragmentation

Christoph Lameter
2008-01-10T19:51:22Z

On Thu, 10 Jan 2008, Matt Mackall wrote:

> Well, I think we'd still have the same page size, in the sense that we'd
> have a struct page for every hardware page and we'd still have hardware
> page-sized pages in the page cache. We'd just change how we allocated
> them. Right now we've got a stack that looks like:

We would not change the hardware page. Cannot do that. But we would have
preferential threadment for 64k and 2M pages in the page allocator?

> buddy / page allocator
> SL*B allocator
> kmalloc
>
> And we'd change that to:
>
> buddy allocator
> SL*B allocator
> page allocator / kmalloc
>
> So get_free_page() would still hand you back a hardware page, it would
> just do it through SL*B.

Hmm.... Not sure what effect this would have. We already have the pcp's
that have a similar effect.

> > It would decrease listlock effect drastically for SLUB.
>
> Not sure what you're referring to here.

Allocations in 64k chunks means 16 times less basic allocation blocks to
manage for the slab allocators. So the metadata to be maintained by the
allocators is reduces by that factor. SLUB only needs to touch the
list_lock (in some situations like a free to a non cpu slab) if a block
becomes completely empty or is going from fully allocated to partially
allocated. The larger the block size the more objects are in a block and
the less of these actions that need a per node lock are needed.