* Re: + hugetlb-allow-extending-ftruncate-on-hugetlbfs.patch added to -mm tree
2007-08-07 4:28 ` + hugetlb-allow-extending-ftruncate-on-hugetlbfs.patch added to -mm tree Ken Chen
@ 2007-08-07 6:44 ` David Gibson
0 siblings, 0 replies; 2+ messages in thread
From: David Gibson @ 2007-08-07 6:44 UTC (permalink / raw)
To: Ken Chen; +Cc: akpm, agl, nacc, wli, linux-mm
On Mon, Aug 06, 2007 at 09:28:01PM -0700, Ken Chen wrote:
> On 8/6/07, David Gibson <david@gibson.dropbear.id.au> wrote:
> > Ken, is this quite sufficient? At least if we're expanding a
> > MAP_SHARED hugepage mapping, we should pre-reserve hugepages on an
> > expanding ftruncate().
>
> why do we need to reserve them? mmap segments aren't extended, e.g.
> vma length remains the same. We only expand file size.
Well.. I suppose it doesn't have to (sorry, I was thinking of my old
version of reservation, where the file's reserve was based on the file
size rather than permitting non-contiguous reserved regions).
But since ftruncate()ing to shorten unreserves pages, it would seem
logical that ftruncate()ing to lengthen would reserve them. In
general the notion of reserved pages for shared mappings is a
reservation in the inode address space, rather than a reservation for
any process's particular mapping of it.
--
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, 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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 2+ messages in thread