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 > > Using my super powers it took me all of three minutes. > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/old-2.6-bkcvs.git > > Do `git log > foo', and search foo for GFP_REPEAT. > > A couple of interesting ones are: > Ok, so __GFP_REPEAT was used to replace the open-coding of retry loops by putting that logic into the page allocator, and that logic was subsequently changed to tie the bit to how many pages were reclaimed and retry iff we haven't reclaimed the number of pages needed (in my patch, that would be a single page). It also shows that the page allocator has infinitely looped for allocations under PAGE_ALLOC_COSTLY_ORDER since your patch from over seven years ago. So, given the fact that the PAGE_ALLOC_COSTLY_ORDER logic has existed since the same time, the semantics of __GFP_REPEAT have changed and are often misrepresented, and we don't even invoke the __GFP_REPEAT logic for any of the allocations in my patch since they are oom killable, I think my patch should be merged. -- 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>