Re: [PATCH][UPDATED] hugetlb: retry pool allocation attempts

[Dave Hansen <haveblue@us.ibm.com>]

On Thu, 2007-11-15 at 12:18 -0800, Nishanth Aravamudan wrote:
> b) __alloc_pages() does not currently retry allocations for order >
> PAGE_ALLOC_COSTLY_ORDER.

... when __GFP_REPEAT has not been specified, right?

> Modify __alloc_pages() to retry GFP_REPEAT COSTLY_ORDER allocations up
> to COSTLY_ORDER_RETRY_ATTEMPTS times, which I've set to 5, and use
> GFP_REPEAT in the hugetlb pool allocation. 5 seems to give reasonable
> results for x86, x86_64 and ppc64, but I'm not sure how to come up with
> the "best" number here (suggestions are welcome!). With this patch
> applied, the same box that gave the above results now gives: 

Coding in an explicit number of retries like this seems a bit hackish to
me.  Retrying the allocations N times internally (through looping)
should give roughly the same number of huge pages that retrying them N
times externally (from the /proc file).  Does doing another ~50
allocations get you to the same number of huge pages?

What happens if you *only* specify GFP_REPEAT from hugetlbfs?

I think you're asking a bit much of the page allocator (and reclaim)
here.  There is a discrete amount of memory pressure applied for each
allocator request.  Increasing the number of requests will virtually
always increase the memory pressure and make more pages available.

What is the actual behavior that you want to get here?  Do you want that
34th request to always absolutely plateau the number of huge pages?

-- Dave

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