From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with ESMTP id 397C46B0047 for ; Tue, 28 Sep 2010 17:38:02 -0400 (EDT) Date: Tue, 28 Sep 2010 14:36:55 -0700 From: Andrew Morton Subject: Re: [patch] arch: remove __GFP_REPEAT for order-0 allocations Message-Id: <20100928143655.4282a001.akpm@linux-foundation.org> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: David Rientjes 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 03:45:10 -0700 (PDT) David Rientjes wrote: > Order-0 allocations, including quicklist_alloc(), are always under > PAGE_ALLOC_COSTLY_ORDER, so they loop endlessly in the page allocator > already without the need for __GFP_REPEAT. That's only true for the current implementation of the page allocator. If we were to change the page allocator behaviour to not do that (and we change it daily!) then all those callsites which wanted __GFP_REPEAT behaviour will get broken. So someone would need to go back and work out how to unbreak them, if we remembered. Plus there's presumably some documentary benefit in leaving the __GFP_REPEATs in there. Why are those __GFP_REPEATs present at those callsites? What were developers trying to achieve? -- 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