Re: hugepage patches

[Andrew Morton <akpm@digeo.com>]

ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> > 
> > Expanding ftruncate would be nice, but the current way of performing
> > the page instantiation at mmap() time seems sufficient.
> 
> Having an expanding/shrinking ftruncate will trivially allow posix shared
> memory semantics.   
> 
> I am trying to digest the idea of a mmap that grows a file.  There isn't
> anything else that works that way is there?

Not that I can think of.

> It looks like you are removing the limit checking from hugetlbfs, by
> removing the expansion code from ftruncate.

There was no expansion code.

The code I took out was vestigial.  We can put it all back if we decide to
add a new expand-with-ftruncate feature to hugetlbfs.

>  And given the fact that
> nothing else grows in mmap, I suspect the code will be much easier to
> write and maintain if the growth is constrained to happen in ftruncate.

That would require a fault handler.  We don't have one of those for hugetlbs.
 Probably not hard to add one though.

> I may be missing something but it looks like there is not code present
> to prevent multiple page allocations at the same time conflicting
> when i_size is grown. 

All the mmap code runs under down_write(current->mm->mmap_sem);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/