On Wed, 2008-08-06 at 10:02 +0100, Mel Gorman wrote: > > That said, this particular patch doesn't appear *too* bound to hugetlb > > itself. But, some of its limitations *do* come from the filesystem, > > like its inability to handle VM_GROWS... > > The lack of VM_GROWSX is an issue, but on its own it does not justify > the amount of churn necessary to support direct pagetable insertions for > MAP_ANONYMOUS|MAP_PRIVATE. I think we'd need another case or two that would > really benefit from direct insertions to pagetables instead of hugetlbfs so > that the path would get adequately tested.
I'm jumping around here a bit, but I'm trying to get to the core of what my problem with these patches is. I'll see if I can close the loop here. The main thing this set of patches does that I care about is take an anonymous VMA and replace it with a hugetlb VMA. It does this on a special cue, but does it nonetheless. This patch has crossed a line in that it is really the first *replacement* of a normal VMA with a hugetlb VMA instead of the creation of the VMAs at the user's request. I'm really curious what the plan is to follow up on this. Will this stack stuff turn out to be one-off code, or is this *the* route for getting transparent large pages in the future? Because of the limitations like its inability to grow the VMA, I can't imagine that this would be a generic mechanism that we can use elsewhere. -- Dave _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
