From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 23 May 2008 07:03:47 +0200 From: Nick Piggin Subject: Re: [patch 02/18] hugetlb: factor out huge_new_page Message-ID: <20080523050346.GC13071@wotan.suse.de> References: <481183FC.9060408@firstfloor.org> <20080425165424.GA9680@us.ibm.com> <20080425192942.GB14623@us.ibm.com> <20080430204428.GC6903@us.ibm.com> <20080501202520.GA12354@us.ibm.com> <20080501210116.GB12354@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080501210116.GB12354@us.ibm.com> Sender: owner-linux-mm@kvack.org Return-Path: To: Nishanth Aravamudan Cc: Christoph Lameter , Andi Kleen , akpm@linux-foundation.org, linux-mm@kvack.org, kniht@linux.vnet.ibm.com, abh@cray.com, wli@holomorphy.com List-ID: On Thu, May 01, 2008 at 02:01:16PM -0700, Nishanth Aravamudan wrote: > On 01.05.2008 [13:34:23 -0700], Christoph Lameter wrote: > > On Thu, 1 May 2008, Nishanth Aravamudan wrote: > > > > > I'm pretty sure when I first created alloc_huge_page_node(), you argued > > > for me *not* using page_to_nid() on the returned page because we expect > > > __GFP_THISNODE to do the right thing. > > > > I vaguely remember that the issue at that point was that you were trying > > to compensate for __GFP_THISNODE brokenness? > > That's a good point -- it was at the time. My point is again here, this > particular callpath *is* using __GPF_THISNODE -- and always will as it's > a node-specific function call. Other callpaths may not, yes, but they > are passing the page in, which means they can call page_to_nid(). Just > seems to calculate a nid we already have. Given the discussion, I'll pass in the nid argument and add a comment. Thanks -- 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: email@kvack.org