This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.5.21s mmap error

On Thu, 13 Jul 2006, Corinna Vinschen wrote:

> I just read the Linux man page (again), and I seem to have missed some
> important bits.  The above semantics are not implemented this way in
> Cygwin.  A private anonymous mmap is actually just an area allocated
> with VirtualAlloc.  A MAP_NORESERVE area is not commited (MEM_COMMIT)
> but just reserved (MEM_RESERVE).  What's missing is the automatic
> commiting when a page fault on one of these pages occurs.

I figured as much based on your previous response, but I wanted to point
out that that was not the typical meaning of MAP_NORESERVE.

> I added an (hopefully) appropriate patch, which commits a page within a
> MAP_NORESERVE area when memory in this page is accessed by the
> application.  If commiting the memory fails, SIGBUS is generated. Please
> test CVS HEAD or the next developer snapshot from

Wow!  Thanks.  Given my limited Windows API knowledge, that sounded
difficult to accomplish properly.  I'll test it for you shortly.

> Note however, that MAP_NORESERVE is only implemented for private
> anonymous mappings.

I think the private restriction is typical, so...

> Shared anonymous maps seem to be possible (and would probably make sense
> to minimze the swap space footprint), but are somewhat tricky since it's
> not quite clear what happens to memory which is commited in one process
> and then accessed in another.  This would require some extensive testing
> which I'm not willing to do yet.

Huh, what does a shared anonymous (/dev/zero) mapping even mean?  You
can't modify /dev/zero, so the only thing that makes sense to me is that
changes made would be visible by the whole process tree containing the
mapping?  I'm not aware of any OS that supports this.

> File-backed mappings are always ignoring the MAP_NORESERVE flag and are
> using committed memory, since uncommitted file maps are not supported on
> Windows.

That's too bad :-(.  Does the above mean that a private file-backed
mapping consumes the full mapping size of swap space just in case all the
pages are dirtied?  Obviously, the file is the backing store until the
page is written, so there is no extra swap usage then.

BTW, If you haven't already, you might consider transparently changing
/dev/zero mappings to anonymous ones so MAP_NORESERVE is possible there.

Thanks again.

Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained pilot...


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]