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

[Christoph Hellwig]

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/