From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 2 Apr 2004 16:27:09 +0100 From: Christoph Hellwig Subject: Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix Message-ID: <20040402162709.A4312@infradead.org> References: <20040402001535.GG18585@dualathlon.random> <20040402011627.GK18585@dualathlon.random> <20040401173649.22f734cd.akpm@osdl.org> <20040402020022.GN18585@dualathlon.random> <20040401180802.219ece99.akpm@osdl.org> <20040402022233.GQ18585@dualathlon.random> <20040402070525.A31581@infradead.org> <20040402152240.GA21341@dualathlon.random> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040402152240.GA21341@dualathlon.random>; from andrea@suse.de on Fri, Apr 02, 2004 at 05:22:40PM +0200 Sender: owner-linux-mm@kvack.org Return-Path: To: Andrea Arcangeli Cc: Christoph Hellwig , Andrew Morton , hugh@veritas.com, vrajesh@umich.edu, linux-kernel@vger.kernel.org, linux-mm@kvack.org List-ID: On Fri, Apr 02, 2004 at 05:22:40PM +0200, Andrea Arcangeli wrote: > I already explained the reason of the changes, and they've nothing to do > with hugetlbfs. The whole thing has nothing to do with hugetlbfs. I also > proposed a way to optimize _always_ regardless of hugetlbfs=y or =n, by > just turning my __GFP_NO_COPM into a __GFP_COMP, again regardless of > hugetlbfs. The current mainline code returning different things from > alloc_pages depending on a hugetlbfs compile option is totally broken > and I simply fixed it. this has absolutely nothing to do with the > hugetlbfs users. Umm, the usersn't aren't supposed to dig into the VM internals that deep. Everyone who does has a bug. > The only ones that may not turn it on are probably the embedded people > using a custom kernel, but as I said I strongly doubt they want to risk > to trigger driver bugs with a different alloc_pages API since nobody > tested that API since everybody is going to turn hugetlbfs on. We can make a little poll on lkml, but I bet most kernel developers will have it disabled :) > I'll now look into the bug that you triggered with xfs. Did you ever > test with hugetlbfs=y before btw I for myself haven't run with hugetlfs=y ever and don't really plan to. > (maybe you were one of the users > keeping it off always and now noticing the API changes under you, and > now benefiting from my standardization of the API)? Huh? The callchain comes from generic slab code.. -- 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: aart@kvack.org