linux-kernel - Re: [PATCH 6/6] Use one zonelist that is filtered by nodemask

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]

Date:	Sun, 11 Nov 2007 14:16:10 +0000
From:	mel@...net.ie (Mel Gorman)
To:	Christoph Lameter <clameter@....com>
Cc:	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Nishanth Aravamudan <nacc@...ibm.com>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, rientjes@...gle.com,
	kamezawa.hiroyu@...fujitsu.com
Subject: Re: [PATCH 6/6] Use one zonelist that is filtered by nodemask

On (09/11/07 09:26), Christoph Lameter didst pronounce:
> On Fri, 9 Nov 2007, Lee Schermerhorn wrote:
> 
> > > On the other hand, if we call alloc_pages() with GFP_THISNODE set, there
> > > is no nid to base the allocation on, so we "fallback" to numa_node_id()
> > > [ almost like the nid had been specified as -1 ].
> > > 
> > > So I guess this is logical -- but I wonder, do we have any callers of
> > > alloc_pages(GFP_THISNODE) ? It seems like an odd thing to do, when
> > > alloc_pages_node() exists?
> > 
> > I don't know if we have any current callers that do this, but absent any
> > documentation specifying otherwise, Mel's implementation matches what
> > I'd expect the behavior to be if I DID call alloc_pages with 'THISNODE.
> > However, we could specify that THISNODE is ignored in __alloc_pages()
> > and recommend the use of alloc_pages_node() passing numa_node_id() as
> > the nid parameter to achieve the behavior.  This would eliminate the
> > check for 'THISNODE in __alloc_pages().  Just mask it off before calling
> > down to __alloc_pages_internal().
> > 
> > Does this make sense?
> 
> I like consistency. If someone absolutely wants a local page then 
> specifying GFP_THISNODE to __alloc_pages is okay. Leave as is I guess. 
> 

Agreed.

> What happens though if an MPOL_BIND policy is in effect? The node used 
> must then be the nearest node from the policy mask....
> 

If MPOL_BIND is in effect, the allocation will be filtered based on the
current allowed nodemask. If they specify THISNODE and the specified
node or current node is not in the mask, I would expect the allocation
to fail. Is that unexpected to anybody?

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