Mail Archives: cygwin/2007/01/10/10:38:24
On Fri, 5 Jan 2007, Corinna Vinschen wrote:
> Actually this shows a problem in the mmap implementation with respect to
> MEM_TOP_DOWN. I think, what mmap should actually do is to create a
> lightweight MAP_RESERVE anonymous mapping of the whole requested mapping
> size, then close it again and then reopen it with the address it got
> in this first try. This would probably ensure that the subsequent two
> mapping will work.
Why MAP_RESERVE if the requested mapping is NO_RESERVE? This is just
about whether you have swap (paging file) space initially committed or
not, right?
On Wed, 10 Jan 2007, Corinna Vinschen wrote:
> I implemented the above mentioned technique, which isn't much code
> anyway. It reserves a memory lot big enough to fit in the whole
> mapping, memorizes the address, free's the memory again and then uses
> the new address in the subsequent real mappings.
>
> This should work (knock on wood) on all systems now. My testcases still
> work on my 512 MB machine, so I'd appreciate if you could give the latest
> snapshot a try on /3GB enabled machines.
Yes, this fixes my STC and the application from which it was derived.
Thanks.
Sorry to dig up the dead, but I had a question about your statement here:
From http://www.cygwin.com/ml/cygwin-developers/2004-03/msg00033.html
On Fri, 19 Mar 2004, Corinna Vinschen wrote:
> The 2nd problem: POSIX allows file mappings to exceed the file size,
> Windows doesn't. If the code tries to map a bigger size, the file on
> disk is automatically extended to the size of the map. The current
> solution restricts the mapping always to the end of the file, so that it
> isn't changed by the mapping size. If the offset is beyond EOF, mmap
> fails with ENXIO. My patch uses the AT_EXTENDABLE_FILE flag in a call
> to ZwMapViewOfSection which allows POSIX semantics. But as you might
> guess, this has again a downside. First, it only works since W2K,
> second and worse, it only works with PAGE_READWRITE mapping. Neither
> PAGE_READONLY, nor PAGE_WRITECOPY (aka MAP_PRIVATE) are allowed. Oh
> boy. While PAGE_READONLY can be managed by changing the page protection
> afterwards, I don't see a way to get it right for MAP_PRIVATE.
So you mean that POSIX specifies that when a file is mapped larger
than its size, as read only or private, the on disk file is actually
extended? That would have been completely contrary to what I'd expect
from those two modes. Otherwise, I don't understand this problem.
Also, couldn't Cygwin's mmap extend the file via other means before
mapping?
Also FYI:
You don't need more memory to enable /3GB on your machine. That switch is
just about NT kernel vs. application virtual address space allocation (2G
kernel/2G application or 1G kernel/3G application). If you ever want to
test this, just throw /3GB into your boot.ini and reboot. To revert, just
do the opposite.
Note that for an application to actually see and use the extra 1G of
virtual address space, it must be compiled with the linker switch
--large-address-aware. If not, to the application, it is supposed to
not see any difference. But, prior to your mmap patch, it did.
Note also that we usually run with /3GB /Userva=2800, which means 1.2G
kernel/2.8G application, because we found that certain drivers need that
much kernel space to map their large PCI memories (video cards, image
processing boards, SCSI drivers, etc.)
The PAE stuff discussed by Christopher Layne in this thread does, however,
actually need that much memory for testing.
--
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the best safety device in any aircraft is a well-trained crew...
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -