From: David Rientjes <rientjes@google.com>
To: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@linux-foundation.org>
Subject: Re: [BUGFIX][PATCH] oom-kill: fix NUMA consraint check with nodemask v3
Date: Tue, 10 Nov 2009 19:14:25 -0800 (PST) [thread overview]
Message-ID: <alpine.DEB.2.00.0911101908180.14549@chino.kir.corp.google.com> (raw)
In-Reply-To: <20091111115217.FD56.A69D9226@jp.fujitsu.com>
On Wed, 11 Nov 2009, KOSAKI Motohiro wrote:
> > > {
> > > -#ifdef CONFIG_NUMA
> > > struct zone *zone;
> > > struct zoneref *z;
> > > enum zone_type high_zoneidx = gfp_zone(gfp_mask);
> > > - nodemask_t nodes = node_states[N_HIGH_MEMORY];
> > > + int ret = CONSTRAINT_NONE;
> > >
> > > - for_each_zone_zonelist(zone, z, zonelist, high_zoneidx)
> > > - if (cpuset_zone_allowed_softwall(zone, gfp_mask))
> > > - node_clear(zone_to_nid(zone), nodes);
> > > - else
> > > + /*
> > > + * The nodemask here is a nodemask passed to alloc_pages(). Now,
> > > + * cpuset doesn't use this nodemask for its hardwall/softwall/hierarchy
> > > + * feature. mempolicy is an only user of nodemask here.
> > > + */
> > > + if (nodemask) {
> > > + nodemask_t mask;
> > > + /* check mempolicy's nodemask contains all N_HIGH_MEMORY */
> > > + nodes_and(mask, *nodemask, node_states[N_HIGH_MEMORY]);
> > > + if (!nodes_equal(mask, node_states[N_HIGH_MEMORY]))
> > > + return CONSTRAINT_MEMORY_POLICY;
> > > + }
> >
> > Although a nodemask_t was previously allocated on the stack, we should
> > probably change this to use NODEMASK_ALLOC() for kernels with higher
> > CONFIG_NODES_SHIFT since allocations can happen very deep into the stack.
>
> No. NODEMASK_ALLOC() is crap. we should remove it.
I've booted 1K node systems and have found it to be helpful to ensure that
the stack will not overflow especially in areas where we normally are deep
already, such as in the page allocator.
> btw, CPUMASK_ALLOC was already removed.
I don't remember CPUMASK_ALLOC() actually being merged. I know the
comment exists in nodemask.h, but I don't recall any CPUMASK_ALLOC() users
in the tree.
--
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:[~2009-11-11 3:14 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-04 8:09 [BUGFIX][PATCH] oom-kill: fix NUMA consraint check with nodemask KAMEZAWA Hiroyuki
2009-11-06 0:02 ` [BUGFIX][PATCH] oom-kill: fix NUMA consraint check with nodemask v2 KAMEZAWA Hiroyuki
2009-11-10 7:24 ` KOSAKI Motohiro
2009-11-10 7:24 ` KAMEZAWA Hiroyuki
2009-11-10 7:39 ` KOSAKI Motohiro
2009-11-10 7:40 ` KAMEZAWA Hiroyuki
2009-11-10 8:03 ` Daisuke Nishimura
2009-11-10 8:17 ` KAMEZAWA Hiroyuki
2009-11-11 2:24 ` [BUGFIX][PATCH] oom-kill: fix NUMA consraint check with nodemask v3 KAMEZAWA Hiroyuki
2009-11-11 2:36 ` KOSAKI Motohiro
2009-11-11 2:49 ` David Rientjes
2009-11-11 3:02 ` KOSAKI Motohiro
2009-11-11 3:10 ` KAMEZAWA Hiroyuki
2009-11-11 3:14 ` David Rientjes [this message]
2009-11-11 3:23 ` KOSAKI Motohiro
2009-11-11 3:27 ` David Rientjes
2009-11-11 3:04 ` KAMEZAWA Hiroyuki
2009-11-11 4:45 ` [BUGFIX][PATCH] oom-kill: fix NUMA consraint check with nodemask v4 KAMEZAWA Hiroyuki
2009-11-11 5:28 ` [BUGFIX][PATCH] oom-kill: fix NUMA consraint check with nodemask v4.1 KAMEZAWA Hiroyuki
2009-11-11 5:58 ` David Rientjes
2009-11-11 6:20 ` KAMEZAWA Hiroyuki
2009-11-11 6:26 ` David Rientjes
2009-11-11 6:34 ` [BUGFIX][PATCH] oom-kill: fix NUMA consraint check with nodemask v4.2 KAMEZAWA Hiroyuki
2009-11-11 7:32 ` David Rientjes
2009-11-18 0:11 ` David Rientjes
2009-11-18 0:58 ` KAMEZAWA Hiroyuki
2009-11-18 2:13 ` David Rientjes
2009-12-15 1:16 ` Andrew Morton
2009-12-15 1:32 ` KAMEZAWA Hiroyuki
2009-12-15 1:38 ` KOSAKI Motohiro
2009-12-15 4:30 ` David Rientjes
2009-12-15 4:35 ` KAMEZAWA Hiroyuki
2009-12-15 4:54 ` David Rientjes
2009-12-15 5:19 ` KOSAKI Motohiro
2009-12-17 22:21 ` David Rientjes
2009-12-18 4:30 ` KOSAKI Motohiro
2009-12-18 10:04 ` David Rientjes
2009-12-15 4:57 ` KAMEZAWA Hiroyuki
2009-12-15 4:43 ` KAMEZAWA Hiroyuki
2009-12-15 4:57 ` David Rientjes
2009-12-15 5:09 ` KAMEZAWA Hiroyuki
2009-12-17 22:23 ` David Rientjes
2009-12-17 23:33 ` KAMEZAWA Hiroyuki
2009-12-15 4:47 ` KOSAKI Motohiro
2009-12-15 5:03 ` David Rientjes
2009-11-18 1:41 ` Daisuke Nishimura
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.00.0911101908180.14549@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nishimura@mxp.nes.nec.co.jp \
/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