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

[Andrea Arcangeli]

On Fri, Apr 02, 2004 at 07:05:25AM +0100, Christoph Hellwig wrote:
> On Fri, Apr 02, 2004 at 04:22:33AM +0200, Andrea Arcangeli wrote:
> > Well, I doubt anybody could take advantage of this optimization, since
> > nobody can ship with hugetlbfs disabled anyways (peraphs with the
> > exception of the embedded people but then I doubt they want to risk
> 
> Common. stop smoking that bad stuff.  Almost non-one except the known
> oracle whores SuSE and RH need it.  Remeber Linux is used much more widely
> except the known "Enterprise" vendors.  None of the NAS/networking/media
> applicances or pdas I've seen has the slightest need for hugetlbfs.

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.

About your comment about SUSE and RH being the only ones shipping with
hugetlbfs turned on, I very strongly doubt that any other distribution
can ship with hugetlbfs turned off, just go ask them, I bet you will
have a surprised that they turn it on too.

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.

As far as I can tell the number of people that runs with hugetlbfs off
is a niche compared to the ones that will turn it on and you're totally
wrong about claiming the opposite. You're confusing the number of active
hugetlbfs users with the number of users that have a kernel compiled
with hugetlbfs=y. That's a completely different thing. And regardless I
proposed a way to optimize it. Plus I fixed a very bad bug that triggers
with hugetlbfs=n and that obviously nobody tested, expce the
CONFIG_MMU=n people, that infact had it fixed only for CONFIG_MM=n, that
as well was totally broken since the alloc_pages API must be indipendent
from CONFIG_MMU, that's a physical-memory thing. So stop making
aggressive claims on l-k, especially when you're wrong.

I'll now look into the bug that you triggered with xfs. Did you ever
test with hugetlbfs=y before btw (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)? Could be a bug in my
changes too (though it works fine for me), we'll see.

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