[RFC] [PATCH 0/5 V2] Huge page backed user-space stacks

[Mel Gorman]

On (05/08/08 10:53), Dave Hansen didst pronounce:
> 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.
> 

I'm not keen on the idea of introducing another specialised path just for
stacks. Testing coverage is tricky enough as it is and problems still slip
through occasionally. Maybe going through hugetlbfs is less than ideal,
but at least it is a shared path.

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

Not much harder than it is to write any alternative in the first place
:/

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

So far, it is working out as a decent model. It is able to track reservations
and deal with the differences between SHARED and PRIVATE without massive
difficulties. While we could add another specialised path to directly insert
the pages into pagetables for private mappings, I find it hard to justify
adding more test coverage problems. There might be minimal gains to be had
in lock granularity but that's about it.

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

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab