linux-kernel - Re: [PATCH 0/3] Use one zonelist per node instead of multiple zonelists v2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070809144726.GA22405@skynet.ie>
Date:	Thu, 9 Aug 2007 15:47:26 +0100
From:	mel@...net.ie (Mel Gorman)
To:	Lee Schermerhorn <Lee.Schermerhorn@...com>
Cc:	Christoph Lameter <clameter@....com>, pj@....com, ak@...e.de,
	kamezawa.hiroyu@...fujitsu.com, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 0/3] Use one zonelist per node instead of multiple zonelists v2

On (08/08/07 18:40), Lee Schermerhorn didst pronounce:
> On Wed, 2007-08-08 at 22:44 +0100, Mel Gorman wrote:
>
> <SNIP>
>
> > 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? 

Yes, it gets the zonelist from the node and uses a nodemask to ignore
zones within it.

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

You have the local node_id to lookup the zonelist with. The policy
provides a nodemask then instead of a zonelist for filtering purposes.

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

The starting node can be determined from where we are currently running
on. Even if the local node is not in the nodemask, we'd still filter it
as normal.

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

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/