All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Mel Gorman <mel@skynet.ie>
Cc: Christoph Lameter <clameter@sgi.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 0/3] Use one zonelist per node instead of multiple zonelists v2
Date: Wed, 08 Aug 2007 18:40:07 -0400	[thread overview]
Message-ID: <1186612807.5055.106.camel@localhost> (raw)
In-Reply-To: <20070808214420.GD2441@skynet.ie>

On Wed, 2007-08-08 at 22:44 +0100, Mel Gorman wrote:
> On (08/08/07 14:30), Lee Schermerhorn didst pronounce:
> > On Wed, 2007-08-08 at 10:36 -0700, Christoph Lameter wrote:
> > > On Wed, 8 Aug 2007, Mel Gorman wrote:
> > > 
<snip>
> > > > o Remove bind_zonelist() (Patch in progress, very messy right now)
> > > 
> > > Will this also allow us to avoid always hitting the first node of an 
> > > MPOL_BIND first?
> > 
> > An idea:
> > 
> > Apologies if someone already suggested this and I missed it.  Too much
> > traffic...
> > 
> > instead of passing a zonelist for BIND policy, how about passing [to
> > __alloc_pages(), I think] a starting node, a nodemask, and gfp flags for
> > zone and modifiers. 
> 
> Yes, this has come up before although it wasn't my initial suggestion. I
> thought maybe it was yours but I'm not sure anymore. I'm working through
> it at the moment. 

I've heard/seen Christoph mention passing a nodemask to alloc_pages a
few times, but hadn't seen any of the details.  Got me thinking..

> With the patch currently, a a nodemask is passed in for
> filtering which should be enough as the zonelist being used should be enough
> information to indicate the starting node.

It'll take me a while to absorb the patch, so I'll just ask:  Where does
the zonelist for the argument come from?  If the the bind policy
zonelist is removed, then does it come from a node?  There'll be only
one per node with your other patches, right?  So you had to have a node
id, to look up the zonelist?  Do you need the zonelist elsewhere,
outside of alloc_pages()?  If not, why not just let alloc_pages look it
up from a starting node [which I think can be determined from the
policy]?  

OK, that's a lot of questions.  no need to answer.  That's just what I'm
thinking re: all this.  I'll wait and see how the patch develops.
  
> 
> The signature of __alloc_pages() becomes
> 
> static page * fastcall
> __alloc_pages_nodemask(gfp_t gfp_mask, nodemask_t *nodemask,
>                unsigned int order, struct zonelist *zonelist)
> 
> >  For various policies, the arguments would look like this:
> > Policy		start node	nodemask
> > 
> > default		local node	cpuset_current_mems_allowed
> > 
> > preferred	preferred_node	cpuset_current_mems_allowed
> > 
> > interleave	computed node	cpuset_current_mems_allowed
> > 
> > bind		local node	policy nodemask [replaces bind
> > 				zonelist in mempolicy]
> > 
> 
> The last one is the most interesting. Much of the patch in development
> involves deleting the custom node stuff. I've included the patch below if
> you're curious. I wanted to get one-zonelist out first to see if we could
> agree on that before going further with it.

Again, it'll be a while. 

Thanks,
Lee



WARNING: multiple messages have this Message-ID (diff)
From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Mel Gorman <mel@skynet.ie>
Cc: Christoph Lameter <clameter@sgi.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 0/3] Use one zonelist per node instead of multiple zonelists v2
Date: Wed, 08 Aug 2007 18:40:07 -0400	[thread overview]
Message-ID: <1186612807.5055.106.camel@localhost> (raw)
In-Reply-To: <20070808214420.GD2441@skynet.ie>

On Wed, 2007-08-08 at 22:44 +0100, Mel Gorman wrote:
> On (08/08/07 14:30), Lee Schermerhorn didst pronounce:
> > On Wed, 2007-08-08 at 10:36 -0700, Christoph Lameter wrote:
> > > On Wed, 8 Aug 2007, Mel Gorman wrote:
> > > 
<snip>
> > > > o Remove bind_zonelist() (Patch in progress, very messy right now)
> > > 
> > > Will this also allow us to avoid always hitting the first node of an 
> > > MPOL_BIND first?
> > 
> > An idea:
> > 
> > Apologies if someone already suggested this and I missed it.  Too much
> > traffic...
> > 
> > instead of passing a zonelist for BIND policy, how about passing [to
> > __alloc_pages(), I think] a starting node, a nodemask, and gfp flags for
> > zone and modifiers. 
> 
> Yes, this has come up before although it wasn't my initial suggestion. I
> thought maybe it was yours but I'm not sure anymore. I'm working through
> it at the moment. 

I've heard/seen Christoph mention passing a nodemask to alloc_pages a
few times, but hadn't seen any of the details.  Got me thinking..

> With the patch currently, a a nodemask is passed in for
> filtering which should be enough as the zonelist being used should be enough
> information to indicate the starting node.

It'll take me a while to absorb the patch, so I'll just ask:  Where does
the zonelist for the argument come from?  If the the bind policy
zonelist is removed, then does it come from a node?  There'll be only
one per node with your other patches, right?  So you had to have a node
id, to look up the zonelist?  Do you need the zonelist elsewhere,
outside of alloc_pages()?  If not, why not just let alloc_pages look it
up from a starting node [which I think can be determined from the
policy]?  

OK, that's a lot of questions.  no need to answer.  That's just what I'm
thinking re: all this.  I'll wait and see how the patch develops.
  
> 
> The signature of __alloc_pages() becomes
> 
> static page * fastcall
> __alloc_pages_nodemask(gfp_t gfp_mask, nodemask_t *nodemask,
>                unsigned int order, struct zonelist *zonelist)
> 
> >  For various policies, the arguments would look like this:
> > Policy		start node	nodemask
> > 
> > default		local node	cpuset_current_mems_allowed
> > 
> > preferred	preferred_node	cpuset_current_mems_allowed
> > 
> > interleave	computed node	cpuset_current_mems_allowed
> > 
> > bind		local node	policy nodemask [replaces bind
> > 				zonelist in mempolicy]
> > 
> 
> The last one is the most interesting. Much of the patch in development
> involves deleting the custom node stuff. I've included the patch below if
> you're curious. I wanted to get one-zonelist out first to see if we could
> agree on that before going further with it.

Again, it'll be a while. 

Thanks,
Lee


--
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 22:40 UTC|newest]

Thread overview: 46+ 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 ` Mel Gorman
2007-08-08 16:15 ` [PATCH 1/3] Use zonelists instead of zones when direct reclaiming pages Mel Gorman
2007-08-08 16:15   ` Mel Gorman
2007-08-08 17:38   ` Christoph Lameter
2007-08-08 17:38     ` Christoph Lameter
2007-08-08 21:06     ` Mel Gorman
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 16:15   ` Mel Gorman
2007-08-08 17:46   ` Christoph Lameter
2007-08-08 17:46     ` Christoph Lameter
2007-08-08 21:10     ` Mel Gorman
2007-08-08 21:10       ` Mel Gorman
2007-08-08 23:28       ` Christoph Lameter
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 16:16   ` 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 17:36   ` Christoph Lameter
2007-08-08 18:30   ` Lee Schermerhorn
2007-08-08 18:30     ` Lee Schermerhorn
2007-08-08 21:44     ` Mel Gorman
2007-08-08 21:44       ` Mel Gorman
2007-08-08 22:40       ` Lee Schermerhorn [this message]
2007-08-08 22:40         ` Lee Schermerhorn
2007-08-08 23:37         ` Christoph Lameter
2007-08-08 23:37           ` Christoph Lameter
2007-08-09 14:47         ` Mel Gorman
2007-08-09 14:47           ` Mel Gorman
2007-08-08 23:35       ` Christoph Lameter
2007-08-08 23:35         ` Christoph Lameter
2007-08-08 21:04   ` Mel Gorman
2007-08-08 21:04     ` Mel Gorman
2007-08-08 23:26     ` Christoph Lameter
2007-08-08 23:26       ` Christoph Lameter
2007-08-09 20:19 ` Andrew Morton
2007-08-09 20:19   ` Andrew Morton
2007-08-09 20:33   ` Christoph Lameter
2007-08-09 20:33     ` Christoph Lameter
2007-08-09 20:51   ` Mel Gorman
2007-08-09 20:51     ` Mel Gorman
2007-08-09 21:20   ` Andi Kleen
2007-08-09 21:20     ` Andi Kleen
2007-08-09 21:40     ` Christoph Lameter
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=1186612807.5055.106.camel@localhost \
    --to=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=mel@skynet.ie \
    --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 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.