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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 2 Aug 2011 11:47:10 -0500 (CDT)
From:	Christoph Lameter <cl@...ux.com>
To:	David Rientjes <rientjes@...gle.com>
cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Andi Kleen <andi@...stfloor.org>, tj@...nel.org,
	Metathronius Galabant <m.galabant@...glemail.com>,
	Matt Mackall <mpm@...enic.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Adrian Drzewiecki <z@...e.net>, linux-kernel@...r.kernel.org
Subject: Re: [slub p3 0/7] SLUB: [RFC] Per cpu partial lists V3

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/