Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix

From: Andrea Arcangeli <andrea@suse.de>
To: Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@osdl.org>,
	hugh@veritas.com, vrajesh@umich.edu,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC][PATCH 1/3] radix priority search tree - objrmap complexity fix
Date: Fri, 2 Apr 2004 17:38:01 +0200	[thread overview]
Message-ID: <20040402153801.GD21341@dualathlon.random> (raw)
In-Reply-To: <20040402162709.A4312@infradead.org>

On Fri, Apr 02, 2004 at 04:27:09PM +0100, Christoph Hellwig wrote:
> 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.

that's why alloc_pages should return the same thing for every user.

> 
> > 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 :)

100 kernel developers, who cares about saving some cycles in 100
machines? Get real.

> > 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.

Now I get a crash in swap resume (I cannot test swap resume yet, at
least now swap suspend works). Could be the same bug you triggered.
We'll see.

> Huh?  The callchain comes from generic slab code..

slab code may be using multipages too. Anyways I had no time to look
into it yet, so give me a bit of time, I need to fix swap resume now,
after that works I'll check if your bug can be explained by the same
issue that swap resume has right now, and if not I'll fix it, then I'll
do mprotect merging (for file mappings too!).