From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with ESMTP id 649176B0047 for ; Tue, 28 Sep 2010 19:52:22 -0400 (EDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id o8SNqIIk030131 for ; Tue, 28 Sep 2010 16:52:18 -0700 Received: from pvh1 (pvh1.prod.google.com [10.241.210.193]) by kpbe20.cbf.corp.google.com with ESMTP id o8SNqGkD003860 for ; Tue, 28 Sep 2010 16:52:16 -0700 Received: by pvh1 with SMTP id 1so60869pvh.9 for ; Tue, 28 Sep 2010 16:52:16 -0700 (PDT) Date: Tue, 28 Sep 2010 16:52:01 -0700 (PDT) From: David Rientjes Subject: Re: [patch] arch: remove __GFP_REPEAT for order-0 allocations In-Reply-To: <20100928164006.55c442b1.akpm@linux-foundation.org> Message-ID: References: <20100928143655.4282a001.akpm@linux-foundation.org> <20100928155326.9ded5a92.akpm@linux-foundation.org> <20100928164006.55c442b1.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Andrew Morton Cc: Arnd Bergmann , Richard Henderson , Ivan Kokshaysky , Matt Turner , Russell King , Mikael Starvik , Jesper Nilsson , David Howells , Geert Uytterhoeven , Roman Zippel , Michal Simek , Koichi Yasutake , Kyle McMartin , Helge Deller , Benjamin Herrenschmidt , Paul Mackerras , Martin Schwidefsky , Heiko Carstens , Paul Mundt , "David S. Miller" , Jeff Dike , Ingo Molnar , "H. Peter Anvin" , Thomas Gleixner , linux-arch@vger.kernel.org, linux-mm@kvack.org List-ID: 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@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org