From: David Rientjes <rientjes@google.com>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: Li Zefan <lizefan@huawei.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
cgroups@vger.kernel.org, Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>
Subject: Re: [PATCH -mm] slab: fix cpuset check in fallback_alloc
Date: Mon, 11 Aug 2014 14:05:18 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1408111354330.24240@chino.kir.corp.google.com> (raw)
In-Reply-To: <20140811121739.GB18709@esperanza>
On Mon, 11 Aug 2014, Vladimir Davydov wrote:
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1963,7 +1963,7 @@ zonelist_scan:
> >
> > /*
> > * Scan zonelist, looking for a zone with enough free.
> > - * See also __cpuset_node_allowed_softwall() comment in kernel/cpuset.c.
> > + * See __cpuset_node_allowed() comment in kernel/cpuset.c.
> > */
> > for_each_zone_zonelist_nodemask(zone, z, zonelist,
> > high_zoneidx, nodemask) {
> > @@ -1974,7 +1974,7 @@ zonelist_scan:
> > continue;
> > if (cpusets_enabled() &&
> > (alloc_flags & ALLOC_CPUSET) &&
> > - !cpuset_zone_allowed_softwall(zone, gfp_mask))
> > + !cpuset_zone_allowed(zone, gfp_mask))
> > continue;
>
> So, this is get_page_from_freelist. It's called from
> __alloc_pages_nodemask with alloc_flags always having ALLOC_CPUSET bit
> set and from __alloc_pages_slowpath with alloc_flags having ALLOC_CPUSET
> bit set only for __GFP_WAIT allocations. That said, w/o your patch we
> try to respect cpusets for all allocations, including atomic, and only
> ignore cpusets if tight on memory (freelist's empty) for !__GFP_WAIT
> allocations, while with your patch we always ignore cpusets for
> !__GFP_WAIT allocations. Not sure if it really matters though, because
> usually one uses cpuset.mems in conjunction with cpuset.cpus and it
> won't make any difference then. It also doesn't conflict with any cpuset
> documentation.
>
Yeah, that's why I'm asking Li, the cpuset maintainer, if we can do this.
The only thing that we get by falling back to the page allocator slowpath
is that kswapd gets woken up before the allocation is attempted without
ALLOC_CPUSET. It seems pointless to wakeup kswapd when the allocation can
succeed on any node. Even with the patch, if the allocation fails because
all nodes are below their min watermark, then we still fallback to the
slowpath and wake up kswapd but there's nothing much else we can do
because it's !__GFP_WAIT.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2014-08-11 21:05 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-10 17:48 Vladimir Davydov
2014-08-10 22:43 ` David Rientjes
2014-08-11 7:13 ` Vladimir Davydov
2014-08-11 11:37 ` David Rientjes
2014-08-11 12:17 ` Vladimir Davydov
2014-08-11 21:05 ` David Rientjes [this message]
2014-08-15 3:13 ` Li Zefan
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=alpine.DEB.2.02.1408111354330.24240@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizefan@huawei.com \
--cc=penberg@kernel.org \
--cc=vdavydov@parallels.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox