Messages in this thread | | | Date | Thu, 9 Mar 2006 11:22:51 +1100 | From | 'David Gibson' <> | Subject | Re: [PATCH] ftruncate on huge page couldn't extend hugetlb file |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |