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:12:13PM -0800, Chen, Kenneth W wrote:
> David Gibson wrote on Wednesday, March 08, 2006 3:58 PM
> > > Hmm??  I don't think you need to extend the reservation when extending
> > > hugetlb file via ftruncate.  You don't have any vma that pass beyond
> > > current size.  So making a reservation is a wrong thing to do here.
> > 
> > Fwiw, I think truncate *should* extend the reservation.  We have a
> > separate thread arguing about whether we should be reserving by inode
> > length, as I've implemented, or by which ranges are actually mapped
> > (as apw's old path implemented).  As long as it *is* by inode length -
> > so it's conceptually all about the logical file in hugetlbfs, not
> > about any of its mappings - I think it makes sense for an extending
> > truncate() to extend the reservation.  It's not reserving them for any
> > particular mapping, it's reserving them for page cache pages.
> 
> 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".

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