linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
To: David Rientjes <rientjes@google.com>
Cc: kosaki.motohiro@jp.fujitsu.com,
	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: Wed, 11 Nov 2009 12:02:06 +0900 (JST)	[thread overview]
Message-ID: <20091111115217.FD56.A69D9226@jp.fujitsu.com> (raw)
In-Reply-To: <alpine.DEB.2.00.0911101841480.11083@chino.kir.corp.google.com>

Hi

> On Wed, 11 Nov 2009, KAMEZAWA Hiroyuki wrote:
> 
> > Index: mm-test-kernel/drivers/char/sysrq.c
> > ===================================================================
> > --- mm-test-kernel.orig/drivers/char/sysrq.c
> > +++ mm-test-kernel/drivers/char/sysrq.c
> > @@ -339,7 +339,7 @@ static struct sysrq_key_op sysrq_term_op
> >  
> >  static void moom_callback(struct work_struct *ignored)
> >  {
> > -	out_of_memory(node_zonelist(0, GFP_KERNEL), GFP_KERNEL, 0);
> > +	out_of_memory(node_zonelist(0, GFP_KERNEL), GFP_KERNEL, 0, NULL);
> >  }
> >  
> >  static DECLARE_WORK(moom_work, moom_callback);
> > Index: mm-test-kernel/mm/oom_kill.c
> > ===================================================================
> > --- mm-test-kernel.orig/mm/oom_kill.c
> > +++ mm-test-kernel/mm/oom_kill.c
> > @@ -196,27 +196,45 @@ unsigned long badness(struct task_struct
> >  /*
> >   * Determine the type of allocation constraint.
> >   */
> > +#ifdef CONFIG_NUMA
> >  static inline enum oom_constraint constrained_alloc(struct zonelist *zonelist,
> > -						    gfp_t gfp_mask)
> > +				    gfp_t gfp_mask, nodemask_t *nodemask)
> 
> We should probably remove the inline specifier, there's only one caller 
> currently and if additional ones were added in the future this function 
> should probably not be replicated.

Good catch.


> >  {
> > -#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. 
btw, CPUMASK_ALLOC was already removed.


> There should be a way around that, however.  Shouldn't
> 
> 	if (nodes_subset(node_states[N_HIGH_MEMORY], *nodemask))
> 		return CONSTRAINT_MEMORY_POLICY;
> 
> be sufficient?

Is this safe on memory hotplug case?




--
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>

  reply	other threads:[~2009-11-11  3:02 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 [this message]
2009-11-11  3:10                     ` KAMEZAWA Hiroyuki
2009-11-11  3:14                     ` David Rientjes
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=20091111115217.FD56.A69D9226@jp.fujitsu.com \
    --to=kosaki.motohiro@jp.fujitsu.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux-foundation.org \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nishimura@mxp.nes.nec.co.jp \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox