Re: [patch 02/18] hugetlb: factor out huge_new_page

[Nishanth Aravamudan <nacc@us.ibm.com>]

On 23.04.2008 [11:53:04 +1000], npiggin@suse.de wrote:
> Needed to avoid code duplication in follow up patches.
> 
> This happens to fix a minor bug. When alloc_bootmem_node returns
> a fallback node on a different node than passed the old code
> would have put it into the free lists of the wrong node.
> Now it would end up in the freelist of the correct node.

This is rather frustrating. The whole point of having the __GFP_THISNODE
flag is to indicate off-node allocations are *not* supported from the
caller... This was all worked on quite heavily a while back.

I expect this will lead to imbalanced allocations, as hugetlb.c will
assume that the previous node successfully allocated and move the
iterator forward, allocating again on the fallback node. Since hugetlb
code will anyways iterate over the nodes appropriately, can't we just
make alloc_bootmem_node (or the eventual call-path that results therein)
do the right thing for __GFP_THISNODE allocations? Minimally, the
varying semantics need to be documented somewhere...

Thanks,
Nish

-- 
Nishanth Aravamudan <nacc@us.ibm.com>
IBM Linux Technology Center

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