All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
To: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@suse.cz>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] mm: exclude memory less nodes from zone_reclaim
Date: Wed, 19 Feb 2014 15:05:58 -0800	[thread overview]
Message-ID: <20140219230558.GA28062@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402191353540.31921@chino.kir.corp.google.com>

On 19.02.2014 [13:56:00 -0800], David Rientjes wrote:
> On Wed, 19 Feb 2014, Nishanth Aravamudan wrote:
> 
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index 3e953f07edb0..4a44bdc7a8cf 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -1855,7 +1855,7 @@ static void __paginginit init_zone_allows_reclaim(int nid)
> > >  {
> > >  	int i;
> > > 
> > > -	for_each_online_node(i)
> > > +	for_each_node_state(i, N_HIGH_MEMORY)
> > >  		if (node_distance(nid, i) <= RECLAIM_DISTANCE)
> > >  			node_set(i, NODE_DATA(nid)->reclaim_nodes);
> > >  		else
> > > @@ -4901,7 +4901,8 @@ void __paginginit free_area_init_node(int nid, unsigned long *zones_size,
> > > 
> > >  	pgdat->node_id = nid;
> > >  	pgdat->node_start_pfn = node_start_pfn;
> > > -	init_zone_allows_reclaim(nid);
> > > +	if (node_state(nid, N_HIGH_MEMORY))
> > > +		init_zone_allows_reclaim(nid);
> > 
> > I'm still new to this code, but isn't this saying that if a node has no
> > memory, then it shouldn't reclaim from any node? But, for a memoryless
> > node to ensure progress later if reclaim is necessary, it *must* reclaim
> > from other nodes? So wouldn't we want to set reclaim_nodes() in that
> > case to node_states[N_MEMORY]?
> > 
> 
> The only time when pgdat->reclaim_nodes or zone_reclaim_mode matters is 
> when iterating through a zonelist for page allocation and a memoryless 
> node should never appear in a zonelist for page allocation, so this is 
> just preventing setting zone_reclaim_mode unnecessarily because the only 
> nodes with > RECLAIM_DISTANCE to another node are memoryless.  So this 
> patch is fine as long as it gets s/N_HIGH_MEMORY/N_MEMORY/.

Ah yes, sorry, I've been looking at this code perhaps too much and going
a bit cross-eyed!

I wonder if we should also put some comments in? But

Acked-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Tested-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>

Thanks,
Nish

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

WARNING: multiple messages have this Message-ID (diff)
From: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
To: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@suse.cz>,
	linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] mm: exclude memory less nodes from zone_reclaim
Date: Wed, 19 Feb 2014 15:05:58 -0800	[thread overview]
Message-ID: <20140219230558.GA28062@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1402191353540.31921@chino.kir.corp.google.com>

On 19.02.2014 [13:56:00 -0800], David Rientjes wrote:
> On Wed, 19 Feb 2014, Nishanth Aravamudan wrote:
> 
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index 3e953f07edb0..4a44bdc7a8cf 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -1855,7 +1855,7 @@ static void __paginginit init_zone_allows_reclaim(int nid)
> > >  {
> > >  	int i;
> > > 
> > > -	for_each_online_node(i)
> > > +	for_each_node_state(i, N_HIGH_MEMORY)
> > >  		if (node_distance(nid, i) <= RECLAIM_DISTANCE)
> > >  			node_set(i, NODE_DATA(nid)->reclaim_nodes);
> > >  		else
> > > @@ -4901,7 +4901,8 @@ void __paginginit free_area_init_node(int nid, unsigned long *zones_size,
> > > 
> > >  	pgdat->node_id = nid;
> > >  	pgdat->node_start_pfn = node_start_pfn;
> > > -	init_zone_allows_reclaim(nid);
> > > +	if (node_state(nid, N_HIGH_MEMORY))
> > > +		init_zone_allows_reclaim(nid);
> > 
> > I'm still new to this code, but isn't this saying that if a node has no
> > memory, then it shouldn't reclaim from any node? But, for a memoryless
> > node to ensure progress later if reclaim is necessary, it *must* reclaim
> > from other nodes? So wouldn't we want to set reclaim_nodes() in that
> > case to node_states[N_MEMORY]?
> > 
> 
> The only time when pgdat->reclaim_nodes or zone_reclaim_mode matters is 
> when iterating through a zonelist for page allocation and a memoryless 
> node should never appear in a zonelist for page allocation, so this is 
> just preventing setting zone_reclaim_mode unnecessarily because the only 
> nodes with > RECLAIM_DISTANCE to another node are memoryless.  So this 
> patch is fine as long as it gets s/N_HIGH_MEMORY/N_MEMORY/.

Ah yes, sorry, I've been looking at this code perhaps too much and going
a bit cross-eyed!

I wonder if we should also put some comments in? But

Acked-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>
Tested-by: Nishanth Aravamudan <nacc@linux.vnet.ibm.com>

Thanks,
Nish


  reply	other threads:[~2014-02-19 23:06 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18  9:06 ppc: RECLAIM_DISTANCE 10? Michal Hocko
2014-02-18  9:06 ` Michal Hocko
2014-02-18  9:06 ` Michal Hocko
2014-02-18 22:27 ` David Rientjes
2014-02-18 22:27   ` David Rientjes
2014-02-18 22:27   ` David Rientjes
2014-02-19  8:16   ` Michal Hocko
2014-02-19  8:16     ` Michal Hocko
2014-02-19  8:16     ` Michal Hocko
2014-02-19  8:20     ` David Rientjes
2014-02-19  8:20       ` David Rientjes
2014-02-19  8:20       ` David Rientjes
2014-02-19  9:19       ` Michal Hocko
2014-02-19  9:19         ` Michal Hocko
2014-02-19  9:19         ` Michal Hocko
2014-02-19 21:45         ` David Rientjes
2014-02-19 21:45           ` David Rientjes
2014-02-19 21:45           ` David Rientjes
2014-02-18 23:34 ` Nishanth Aravamudan
2014-02-18 23:34   ` Nishanth Aravamudan
2014-02-18 23:34   ` Nishanth Aravamudan
2014-02-18 23:58   ` Nishanth Aravamudan
2014-02-18 23:58     ` Nishanth Aravamudan
2014-02-19  0:40     ` Nishanth Aravamudan
2014-02-19  0:40       ` Nishanth Aravamudan
2014-02-19  1:43     ` David Rientjes
2014-02-19  1:43       ` David Rientjes
2014-02-19  8:33       ` Michal Hocko
2014-02-19  8:33         ` Michal Hocko
2014-02-19  8:33         ` Michal Hocko
2014-02-19 16:24       ` Nishanth Aravamudan
2014-02-19 16:24         ` Nishanth Aravamudan
2014-02-19 16:33         ` Nishanth Aravamudan
2014-02-19 16:33           ` Nishanth Aravamudan
2014-02-20  9:55           ` Michal Hocko
2014-02-20  9:55             ` Michal Hocko
2014-02-20  9:55             ` Michal Hocko
2014-02-19  8:23   ` Michal Hocko
2014-02-19  8:23     ` Michal Hocko
2014-02-19  8:23     ` Michal Hocko
2014-02-19 16:26     ` Nishanth Aravamudan
2014-02-19 16:26       ` Nishanth Aravamudan
2014-02-19 16:26       ` Nishanth Aravamudan
2014-02-19 17:03     ` [RFC PATCH] mm: exclude memory less nodes from zone_reclaim Michal Hocko
2014-02-19 17:03       ` Michal Hocko
2014-02-19 17:16       ` Nishanth Aravamudan
2014-02-19 17:16         ` Nishanth Aravamudan
2014-02-19 17:32         ` Michal Hocko
2014-02-19 17:32           ` Michal Hocko
2014-02-19 17:49           ` Nishanth Aravamudan
2014-02-19 17:49             ` Nishanth Aravamudan
2014-02-19 19:40             ` Michal Hocko
2014-02-19 19:40               ` Michal Hocko
2014-02-19 17:53       ` Nishanth Aravamudan
2014-02-19 17:53         ` Nishanth Aravamudan
2014-02-19 21:56         ` David Rientjes
2014-02-19 21:56           ` David Rientjes
2014-02-19 23:05           ` Nishanth Aravamudan [this message]
2014-02-19 23:05             ` Nishanth Aravamudan
2014-02-20  9:50             ` Michal Hocko
2014-02-20  9:50               ` Michal Hocko

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=20140219230558.GA28062@linux.vnet.ibm.com \
    --to=nacc@linux.vnet.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --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.