Re: [patch] arch: remove __GFP_REPEAT for order-0 allocations

David Rientjes
2010-09-28T23:12:36Z

On Tue, 28 Sep 2010, Andrew Morton wrote:

> > So we can definitely remove __GFP_REPEAT for any order-0 allocation and
> > it's based on its implementation -- poorly defined as it may be -- and the
> > inherit design of any sane page allocator that retries such an allocation
> > if it's going to use reclaim in the first place.
>
> Why was __GFP_REPEAT used in those callsites? What were people trying
> to achieve?
>

I can't predict what they were trying to achieve since the documentation
varies on the semantics of __GFP_REPEAT, but the actual implementation
would suggest that we want to ensure that reclaim actually frees memory
before we fail the allocation, and that was probably done before it was
decided to implicitly loop already for order-3 and smaller allocations and
prehaps even predates the oom killer.

With the oom killer, which would be used iff direct reclaim failed for the
allocs touched in this patch, we can't report how much memory may be freed
when that killed task exits, so we implicitly loop forever regardless of
__GFP_REPEAT (and for a reason other than PAGE_ALLOC_COSTLY_ORDER: if the
oom killer kills or finds a task that has already been killed but yet to
exit, it automatically retries the allocation waiting for that free memory
without even looking at should_alloc_retry()).