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()). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>