Re: [slub p3 0/7] SLUB: [RFC] Per cpu partial lists V3

[Christoph Lameter]

On Tue, 2 Aug 2011, David Rientjes wrote:

> Aside from per-cpu partial lists, I think this particular benchmark would
> benefit from two other changes on my testing environment:
>
>  - remote cpu freeing so that objects allocated on a different cpu get
>    moved to a separate list that will eventually get flushed back to the
>    origin cpu to be reallocated later with sane heuristics to determine
>    when to take the necessary lock and cacheline bounce, and

Remote cpu should scale better now since we only need to acquire the
cacheline of the page struct exclusively. With per cpu partials the
pressure on the node lock is pretty much gone.

>  - a preference to only pull a slab from the partial lists if there are
>    a sane number of free objects risking perhaps a costly page allocation
>    that will nevertheless allow the fastpaths to be exercised a little
>    more either way (this benchmark suffers horribly when only one or two
>    objects can be allocated from a partial slab).

The partial patch will pull a large number of partial slabs off the per
node list if possible.

> > I am currently reworking the patches to operate on a linked list instead
> > of a very small array of pointers to page structs. That will allow much
> > larger per cpu partial lists and a dynamic configuration of the sizes.
> >
>
> Ok, so is the per-cpu partial list patch in this series worth the review
> or are you going to go under the hood and rework it?

No its not worth it right now. There are already too many changes. I can
send you my current patches if you want to get directly involved.
Certainly would appreciate the help.

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