On Tue, 2008-08-05 at 17:28 +0100, Mel Gorman wrote: > Ok sure, you could do direct inserts for MAP_PRIVATE as conceptually it > suits this patch. However, I don't see what you gain. By reusing hugetlbfs, > we get things like proper reservations which we can do for MAP_PRIVATE these > days. Again, we could call that sort of thing directly if the reservation > layer was split out separate from hugetlbfs but I still don't see the gain > for all that churn. > > What am I missing?
This is good for getting us incremental functionality. It is probably the smallest amount of code to get it functional. My concern is that we're going down a path that all large page usage should be through the one and only filesystem. Once we establish that dependency, it is going to be awfully hard to undo it; just think of all of the inherent behavior in hugetlbfs. So, we better be sure that the filesystem really is the way to go, especially if we're going to start having other areas of the kernel depend on it internally. 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... -- Dave _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
