From: Pekka Enberg <penberg@cs.helsinki.fi>
To: David Rientjes <rientjes@google.com>
Cc: Christoph Lameter <cl@linux-foundation.org>,
linux-kernel@vger.kernel.org
Subject: Re: [patch] slub: default min_partial to at least highest cpus per node
Date: Tue, 07 Apr 2009 22:54:38 +0300 [thread overview]
Message-ID: <49DBAF7E.30704@cs.helsinki.fi> (raw)
In-Reply-To: <alpine.DEB.2.00.0904071231500.21113@chino.kir.corp.google.com>
David Rientjes wrote:
> On Tue, 7 Apr 2009, Pekka Enberg wrote:
>
>>> Hmm, partial lists are per-node, so wouldn't it be better to do the
>>> adjustment for every struct kmem_cache_node separately? The
>>> 'min_partial_per_node' global seems just too ugly and confusing to live
>>> with.
>> Btw, that requires moving ->min_partial to struct kmem_cache_node from
>> struct kmem_cache. But I think that makes a whole lot of sense if
>> some nodes may have more CPUs than others.
>>
>> And while the improvement is kinda obvious, I would be interested to
>> know what kind of workload benefits from this patch (and see numbers
>> if there are any).
>>
>
> It doesn't really depend on the workload, it depends on the type of NUMA
> machine it's running on (and whether that NUMA is asymmetric amongst
> cpus).
>
> Since min_partial_per_node is capped at MAX_PARTIAL, this is only really
> relevant for remote node defragmentation if it's allowed (and not just 2%
> of the time like the default). We want to avoid stealing partial slabs
> from remote nodes if there are fewer than the number of cpus on that node.
>
> Otherwise, it's possible for each cpu on the victim node to try to
> allocate a single object and require nr_cpus_node(node) new slab
> allocations. In this case it's entirely possible for the majority of cpus
> to have cpu slabs from remote nodes. This change reduces the liklihood of
> that happening because we'll always have cpu slab replacements on our
> local partial list before allowing remote defragmentation.
>
> I'd be just as happy with the following, although it would require
> changing MIN_PARTIAL to be greater than its default of 5 if a node
> supports more cpus for optimal performance (the old patch did that
> automatically up to MAX_PARTIAL).
Hmm but why not move ->min_partial to struct kmem_cache_node as I
suggested and make sure it's adjusted properly as with nr_cpus_node()?
> diff --git a/mm/slub.c b/mm/slub.c
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1326,11 +1326,13 @@ static struct page *get_any_partial(struct kmem_cache *s, gfp_t flags)
> zonelist = node_zonelist(slab_node(current->mempolicy), flags);
> for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
> struct kmem_cache_node *n;
> + int node;
>
> - n = get_node(s, zone_to_nid(zone));
> + node = zone_to_nid(zone);
> + n = get_node(s, node);
>
> if (n && cpuset_zone_allowed_hardwall(zone, flags) &&
> - n->nr_partial > s->min_partial) {
> + n->nr_partial > nr_cpus_node(node)) {
> page = get_partial_node(n);
> if (page)
> return page;
next prev parent reply other threads:[~2009-04-07 19:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-06 0:52 [patch] slub: default min_partial to at least highest cpus per node David Rientjes
2009-04-07 18:58 ` Pekka Enberg
2009-04-07 19:09 ` Pekka Enberg
2009-04-07 19:44 ` David Rientjes
2009-04-07 19:54 ` Pekka Enberg [this message]
2009-04-07 20:09 ` David Rientjes
2009-04-07 20:11 ` Pekka Enberg
2009-04-07 20:22 ` David Rientjes
2009-04-07 20:35 ` Pekka Enberg
2009-04-07 20:43 ` Christoph Lameter
2009-04-07 20:48 ` Pekka Enberg
2009-04-07 21:31 ` Christoph Lameter
2009-04-07 21:46 ` David Rientjes
2009-04-07 21:48 ` Christoph Lameter
2009-04-07 22:03 ` David Rientjes
2009-04-13 18:07 ` Christoph Lameter
2009-04-07 22:01 ` David Rientjes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49DBAF7E.30704@cs.helsinki.fi \
--to=penberg@cs.helsinki.fi \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.