Messages in this thread | | | 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 |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |