linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: mel@skynet.ie (Mel Gorman)
To: Christoph Lameter <clameter@sgi.com>
Cc: Lee.Schermerhorn@hp.com, pj@sgi.com, ak@suse.de,
	kamezawa.hiroyu@jp.fujitsu.com, akpm@linux-foundation.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 2/3] Use one zonelist that is filtered instead of multiple zonelists
Date: Wed, 8 Aug 2007 22:10:32 +0100	[thread overview]
Message-ID: <20070808211032.GB2441@skynet.ie> (raw)
In-Reply-To: <Pine.LNX.4.64.0708081041240.12652@schroedinger.engr.sgi.com>

On (08/08/07 10:46), Christoph Lameter didst pronounce:
> On Wed, 8 Aug 2007, Mel Gorman wrote:
> 
> >  		for (i = 0; i < npmem_ranges; i++) {
> > +			zl = &NODE_DATA(i)->node_zonelist;
> 
> The above shows up again and again. Maybe add a new inline function?
> 
> struct zonelist *zonelist_node(int node)
> 

Not a bad plan. There are least 5 instances of calls like this in mm/
alone so might as well.

> 
> >  {
> > -	return NODE_DATA(0)->node_zonelists + gfp_zone(gfp_flags);
> > +	return &NODE_DATA(0)->node_zonelist;
> 
> How many callers of gfp_zone are left? Do we still need the function?
> 

Well, the iterator needs it because it expects a high_zoneidx parameter
which is == gfp_zone(gfp_flags). It also appears quite a bit the code
according to grep. I don't think it can be got rid of now anyway.

> Note that the memoryless_node patchset modifies gfp_zone and adds some 
> more zonelists (sigh).
> 
> > diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc1-mm2-005_freepages_zonelist/mm/oom_kill.c linux-2.6.23-rc1-mm2-010_use_zonelist/mm/oom_kill.c
> > --- linux-2.6.23-rc1-mm2-005_freepages_zonelist/mm/oom_kill.c	2007-08-07 14:45:11.000000000 +0100
> > +++ linux-2.6.23-rc1-mm2-010_use_zonelist/mm/oom_kill.c	2007-08-08 11:35:09.000000000 +0100
> > @@ -177,8 +177,10 @@ static inline int constrained_alloc(stru
> >  {
> >  #ifdef CONFIG_NUMA
> >  	struct zone **z;
> > +	struct zone *zone;
> >  	nodemask_t nodes;
> >  	int node;
> > +	enum zone_type high_zoneidx = gfp_zone(gfp_mask);
> >  
> >  	nodes_clear(nodes);
> >  	/* node has memory ? */
> > @@ -186,9 +188,9 @@ static inline int constrained_alloc(stru
> >  		if (NODE_DATA(node)->node_present_pages)
> >  			node_set(node, nodes);
> >  
> > -	for (z = zonelist->zones; *z; z++)
> > -		if (cpuset_zone_allowed_softwall(*z, gfp_mask))
> > -			node_clear(zone_to_nid(*z), nodes);
> > +	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
> >  			return CONSTRAINT_CPUSET;
> >  
> 
> The above portion has already been changed to no longer use a zonelist by 
> the memoryless_node patchset in mm.
> 

Oh, well that's good. One less thing to worry about even though we'll be
colliding a bit. I'll split the patch in two to have the second part that
collides with memoryless_node as a standalone patch.

> > +	zonelist = &NODE_DATA(slab_node(current->mempolicy))->node_zonelist;
> > +	for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
> >  		struct kmem_cache_node *n;
> >  
> > -		n = get_node(s, zone_to_nid(*z));
> > +		n = get_node(s, zone_to_nid(zone));
> 
> Encoding the node in the zonelist pointer would help these loops but they 
> are fallback lists and not on the critical path.
> 

The zone_id is the one I'm really interested in. It looks like the most
promising optimisation for avoiding zone_idx in the hotpath.

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

--
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:[~2007-08-08 21:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-08 16:15 [PATCH 0/3] Use one zonelist per node instead of multiple zonelists v2 Mel Gorman
2007-08-08 16:15 ` [PATCH 1/3] Use zonelists instead of zones when direct reclaiming pages Mel Gorman
2007-08-08 17:38   ` Christoph Lameter
2007-08-08 21:06     ` Mel Gorman
2007-08-08 16:15 ` [PATCH 2/3] Use one zonelist that is filtered instead of multiple zonelists Mel Gorman
2007-08-08 17:46   ` Christoph Lameter
2007-08-08 21:10     ` Mel Gorman [this message]
2007-08-08 23:28       ` Christoph Lameter
2007-08-08 16:16 ` [PATCH 3/3] Apply MPOL_BIND policy to two highest zones when highest is ZONE_MOVABLE Mel Gorman
2007-08-08 17:36 ` [PATCH 0/3] Use one zonelist per node instead of multiple zonelists v2 Christoph Lameter
2007-08-08 18:30   ` Lee Schermerhorn
2007-08-08 21:44     ` Mel Gorman
2007-08-08 22:40       ` Lee Schermerhorn
2007-08-08 23:37         ` Christoph Lameter
2007-08-09 14:47         ` Mel Gorman
2007-08-08 23:35       ` Christoph Lameter
2007-08-08 21:04   ` Mel Gorman
2007-08-08 23:26     ` Christoph Lameter
2007-08-09 20:19 ` Andrew Morton
2007-08-09 20:33   ` Christoph Lameter
2007-08-09 20:51   ` Mel Gorman
2007-08-09 21:20   ` Andi Kleen
2007-08-09 21:40     ` Christoph Lameter

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=20070808211032.GB2441@skynet.ie \
    --to=mel@skynet.ie \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=ak@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pj@sgi.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