From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51]) by kanga.kvack.org (Postfix) with ESMTP id 786CB6B0047 for ; Tue, 28 Sep 2010 21:10:58 -0400 (EDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id o8T1Ate4008031 for ; Tue, 28 Sep 2010 18:10:55 -0700 Received: from pxi4 (pxi4.prod.google.com [10.243.27.4]) by hpaq7.eem.corp.google.com with ESMTP id o8T1AkVQ010718 for ; Tue, 28 Sep 2010 18:10:53 -0700 Received: by pxi4 with SMTP id 4so74653pxi.36 for ; Tue, 28 Sep 2010 18:10:53 -0700 (PDT) Date: Tue, 28 Sep 2010 18:10:43 -0700 (PDT) From: David Rientjes Subject: Re: [patch] arch: remove __GFP_REPEAT for order-0 allocations In-Reply-To: <20100928174147.41e48aef.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> <20100928174147.41e48aef.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: > What I care about is that very smart, experienced and hard-working > Linux developers decided, a long time ago, that page-table allocations > are special, and need special treatment. This is information! > Then they implemented it incorrectly since __GFP_REPEAT has never given any order-0 allocation special treatment. > What I also care about is lazy MM developers who just rip stuff out > without understanding it and without even bothering to make an > *attempt* to understand it. > I understand that __GFP_REPEAT does absolutely nothing in all the places that I removed it in this patch, but if you want to use a gfp flag as documentation instead of adding a comment to the PAGE_ALLOC_COSTLY_ORDER retry logic, then that's your call, but I would certainly suggest cleaning up the erroneous documentation in the tree that specifies its semantics. > > 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, > > Probably this is because lazy ignorant MM developers broke earlier > intentions without even knowing that they were doing so. > The intention was that they loop forever, but since that's implicit for these order-0 allocations, I guess you allowed its semantics to change in a41f24ea without the same objections? -- 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