From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Han Pingtian <hanpt@linux.vnet.ibm.com>,
Matt Mackall <mpm@selenic.com>,
David Rientjes <rientjes@google.com>,
Pekka Enberg <penberg@kernel.org>,
Linux Memory Management List <linux-mm@kvack.org>,
Paul Mackerras <paulus@samba.org>, Tejun Heo <tj@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
linuxppc-dev@lists.ozlabs.org, Christoph Lameter <cl@linux.com>,
Wanpeng Li <liwanp@linux.vnet.ibm.com>,
Anton Blanchard <anton@samba.org>
Subject: Re: [PATCH 2/3] slub: fallback to node_to_mem_node() node if allocating on memoryless node
Date: Tue, 9 Sep 2014 17:55:42 -0700 [thread overview]
Message-ID: <20140910005542.GI22906@linux.vnet.ibm.com> (raw)
In-Reply-To: <20140909171125.de9844579d55599c59260afb@linux-foundation.org>
On 09.09.2014 [17:11:25 -0700], Andrew Morton wrote:
> On Tue, 9 Sep 2014 12:05:14 -0700 Nishanth Aravamudan <nacc@linux.vnet.ibm.com> wrote:
>
> > From: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> >
> > Update the SLUB code to search for partial slabs on the nearest node
> > with memory in the presence of memoryless nodes. Additionally, do not
> > consider it to be an ALLOC_NODE_MISMATCH (and deactivate the slab) when
> > a memoryless-node specified allocation goes off-node.
> >
> > ...
> >
> > --- a/mm/slub.c
> > +++ b/mm/slub.c
> > @@ -1699,7 +1699,12 @@ static void *get_partial(struct kmem_cache *s, gfp_t flags, int node,
> > struct kmem_cache_cpu *c)
> > {
> > void *object;
> > - int searchnode = (node == NUMA_NO_NODE) ? numa_mem_id() : node;
> > + int searchnode = node;
> > +
> > + if (node == NUMA_NO_NODE)
> > + searchnode = numa_mem_id();
> > + else if (!node_present_pages(node))
> > + searchnode = node_to_mem_node(node);
>
> I expect a call to node_to_mem_node() will always be preceded by a test
> of node_present_pages(). Perhaps node_to_mem_node() should just do the
> node_present_pages() call itself?
Really, we don't need that test here. We could always use the result of
node_to_mem_node() in the else. If memoryless nodes are not supported
(off in .config), then node_to_mem_node() trivially returns. If they are
supported, it returns the correct value for all nodes.
It's just an optimization (premature?) since we can avoid worrying (in
this path) about memoryless nodes if the node in question has memory.
And, in fact, in __slab_alloc(), we could do the following:
...
int searchnode = node;
if (node != NUMA_NO_NODE)
searchnode = node_to_mem_node(node);
if (node != searchnode &&
unlikely(!node_match(page, searchnode))) {
...
which would minimize the impact to non-memoryless node NUMA configs.
Does that seem better to you? I can add comments to this patch as well.
Thanks,
Nish
next prev parent reply other threads:[~2014-09-10 0:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-09 19:01 [PATCH 0/3] Improve slab consumption with memoryless nodes Nishanth Aravamudan
2014-09-09 19:03 ` [PATCH v3] topology: add support for node_to_mem_node() to determine the fallback node Nishanth Aravamudan
2014-09-09 19:05 ` [PATCH 2/3] slub: fallback to node_to_mem_node() node if allocating on memoryless node Nishanth Aravamudan
2014-09-09 19:06 ` [PATCH 3/3] Partial revert of 81c98869faa5 ("kthread: ensure locality of task_struct allocations") Nishanth Aravamudan
2014-09-10 0:11 ` [PATCH 2/3] slub: fallback to node_to_mem_node() node if allocating on memoryless node Andrew Morton
2014-09-10 0:55 ` Nishanth Aravamudan [this message]
2014-09-10 0:11 ` [PATCH v3] topology: add support for node_to_mem_node() to determine the fallback node Andrew Morton
2014-09-10 0:47 ` Nishanth Aravamudan
2014-09-10 19:06 ` Andrew Morton
2014-09-10 22:49 ` Nishanth Aravamudan
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=20140910005542.GI22906@linux.vnet.ibm.com \
--to=nacc@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=anton@samba.org \
--cc=cl@linux.com \
--cc=hanpt@linux.vnet.ibm.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=liwanp@linux.vnet.ibm.com \
--cc=mpm@selenic.com \
--cc=paulus@samba.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=tj@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).