Re: [PATCH 1/4] hugetlb: search harder for memory in alloc_fresh_huge_page()

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

On 06.09.2007 [11:21:34 -0700], Nishanth Aravamudan wrote:
> hugetlb: search harder for memory in alloc_fresh_huge_page()
> 
> Currently, alloc_fresh_huge_page() returns NULL when it is not able to
> allocate a huge page on the current node, as specified by its custom
> interleave variable. The callers of this function, though, assume that a
> failure in alloc_fresh_huge_page() indicates no hugepages can be
> allocated on the system period. This might not be the case, for
> instance, if we have an uneven NUMA system, and we happen to try to
> allocate a hugepage on a node (with __GFP_THISNODE) with less memory and
> fail, while there is still plenty of free memory on the other nodes.
> 
> To correct this, make alloc_fresh_huge_page() search through all online
> nodes before deciding no hugepages can be allocated. Add a helper
> function for actually allocating the hugepage. Also, while we expect
> particular semantics for __GFP_THISNODE, which are newly enforced --
> that is, that the allocation won't go off-node -- still use
> page_to_nid() to guarantee we don't mess up the accounting.

Christoph, Lee, ping? I haven't heard any response on these patches this
time around. Would it be acceptable to ask Andrew to pick them up for
the next -mm?

Andrew, there probably will be conflicts with Lee's nodes_state patches
and perhaps other patches queued for -mm, if you'd like me to
rebase/retest before picking them up.

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>