Re: [PATCH] ftruncate on huge page couldn't extend hugetlb file

["'David Gibson'" <david@gibson.dropbear.id.au>]

On Wed, Mar 08, 2006 at 04:33:10PM -0800, Chen, Kenneth W wrote:
> David Gibson wrote on Wednesday, March 08, 2006 4:23 PM
> > > But you already make reservation at mmap time.  If you reserve it again
> > > when extending the file, won't you double count?
> > 
> > Well, I'd generally expect extending truncate() to come before mmap(),
> > but in any case hugetlb_extend_reservation() is safe against double
> > counting (it's idempotent if called twice with the same number of
> > pages).  The semantics are "ensure the this many pages total are
> > guaranteed available, that is, either reserved or already
> > instantiated".
> 
> It's kind of peculiar that kernel reserve hugetlb page at the time of
> extending truncate.  Maybe there is a close correlation between mmap
> size to the file size.  But these two aren't the same and and shouldn't
> be mixed.

Indeed.  The fundamental basis of my approach as opposed to that in
apw's old accounting patches is that reservation is related to
filesize, not mmap() size.  The only connection to mmap() is that
(shared writable) mmap() on hugetlbfs also extends filesize and
reservation size as a side effect.

There's a slight wrinkle in the different between i_size and reserved
pages.  i_size can be extended beyond the "reserved portion" of the
file.  We need that behaviour because i_size also acts as a hard
offset limit for MAP_PRIVATE mappings, but privately instantiated
pages don't come from the file's reservation.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson