On Tue, Jul 15, 2008 at 04:34:24AM +0100, Mel Gorman wrote:
> On (15/07/08 12:13), David Gibson didst pronounce:
> > On Mon, Jul 14, 2008 at 10:17:00PM +0100, Mel Gorman wrote:
> > > When HUGETLB_SHARE=1, read-only text segments are copied to a file on
> > > a hugetlbfs mount and shared between multiple processes. However with
> > > kernel 2.6.27 and later, the expectation is that pages will be reserved
> > > for
> > > MAP_PRIVATE mappings as well as MAP_SHARED. This will render HUGETLB_SHARE
> > > ineffective as huge pages will be reserved that already exist in the page
> > > cache. This patch disables reservations for read-only mappings when
> > > sharing
> > > is enabled on the assumption mprotect() will never be called for remapped
> > > read-only segments.
> >
> > Sorry, I don't 100% follow what the problem is here. Are you saying
> > the pages get over-reserved, once for the SHARED mapping and once for
> > the PRIVATE? If that's the case, isn't that a kernel bug?
> >
>
> The excessive reservation is due to how libhugetlbfs does the shared
> backing. It first maps MAP_SHARED (taking a reserve), copies the data
> and unmaps the file. The reserves are now consumed and in page cache. It
> later maps that file MAP_PRIVATE (again taking a reserve) but in this
> case we know that the page is already in page cache and a COW will never
> be necessary. At this point, the reserve pages are wasted memory as they
> will never be used. The MAP_NORESERVE is used in this case because we
> know the MAP_PRIVATE mapping will be safe for the lifetime of the
> process and the pages already exist.
>
> The kernel is forced to take a reservation at mmap() time as mprotect()
> could be called making a read-only mapping read-write. At that point, the
> application could fail. In theory, the kernel could force the reservation
> to take place at mprotect() and fail if the reservation could not be made
> but it would be fairly complex and I expect mprotect() failing to be a big
> surprise to a developer and the condition not handled properly.
Ah, ok. So its the fact that we know, or at least assume, that the
read-only mapping will never be mprotect()ed read-write that gives
libhugetlbfs more knowledge than the kernel here. Ok.
--
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
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
