On Fri, Sep 28, 2007 at 08:17:09AM -0500, Adam Litke wrote:
> On Fri, 2007-09-28 at 16:37 +1000, David Gibson wrote:
> > I think the right way to fix this is instead to unify the "normal"
> > remapping path a bit more with the HUGETLB_SHARE path. We would
> > always use named rather than anonymous hugetlbfs files to back the
> > hugepage segments. To populate those hugepage files, rather than
> > using a temporary mapping, we'd actually fork(), and the child process
> > would fill in the hugetlbfs files, then exit(). The main path would
> > wait for that then map the pre-populated files directly into place
> > over the segments, thereby not clobbering any segments we don't have
> > to.
>
> That is definitely an interesting idea.
Actually, it doesn't necessarily need using named hugepage files: we
could fork() after obtaining the fd, but before mapping 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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
