On Fri, Nov 07, 2008 at 10:08:23AM +0000, Mel Gorman wrote:
> On Fri, Nov 07, 2008 at 09:08:14AM +1100, David Gibson wrote:
> > On Thu, Nov 06, 2008 at 11:19:18AM -0600, Adam Litke wrote:
> > > On Thu, 2008-11-06 at 16:20 +0000, Mel Gorman wrote:
[snip]
> > > I think it might be useful to describe in the man page why an _unlinked_
> > > file descriptor is desired. This isn't immediately obvious. Saying
> > > that it makes the fd behave more like anonymous memory (in that the huge
> > > pages are freed after an unmap and the data will not persist) and that
> > > another process cannot open the same fd to snoop data.
> >
> > Uh.. the pages won'tbe freed on unmap, only on close().
> >
>
> In the MAP_PRIVATE case, they get freed and in the MAP_SHARED case, one would
> have to call ftruncate. Yeah, it's not amazingly easy or anything but it's
> doable. Here is a program I linked directly to libhugetlbfs .o files just
> to get the read_meminfo() function. It shows a heap being created, and the
> pages being consumed and then freed as the heap grows and shrinks.
Sure, I get the point. Sorry, I was just being pedantic above.
--
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
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
