This is the mail archive of the
mailing list for the Cygwin project.
Re: 1.5.21s mmap error
On Jul 13 10:07, Brian Ford wrote:
> On Thu, 13 Jul 2006, Corinna Vinschen wrote:
> > 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.
Huh? Say "shared memory" multiple times... think again... and?
> > 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.
Isn't that what !MAP_NORESERVE usually means? To re-quote from your
Without this flag, the creation of a writable MAP_PRIVATE mapping
reserves swap space equal to the size of the mapping.
It might be possible to get MAP_NORESERVE working for files on NT.
I see how it could work, but further mmap enhacements are pretty
low on my overlong TODO list.
> BTW, If you haven't already, you might consider transparently changing
> /dev/zero mappings to anonymous ones so MAP_NORESERVE is possible there.
Did you try it lately, say, in the last 5 1/2 years?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html