X-Spam-Check-By: sourceware.org
Date: Wed, 10 Jan 2007 09:37:45 -0600
From: Brian Ford <Brian DOT Ford AT FlightSafety DOT com>
Reply-To: cygwin AT cygwin DOT com
To: cygwin AT cygwin DOT com
Subject: Re: 1.7.0 CVS mmap failure
In-Reply-To: <20070110095345.GL23638@calimero.vinschen.de>
Message-ID: <Pine.CYG.4.58.0701100903410.3236@PC1163-8460-XP.flightsafety.com>
References: <Pine DOT CYG DOT 4 DOT 58 DOT 0701041715140 DOT 3520 AT PC1163-8460-XP DOT flightsafety DOT com>  <20070105095752 DOT GB28768 AT calimero DOT vinschen DOT de>  <Pine DOT CYG DOT 4 DOT 58 DOT 0701050959060 DOT 2704 AT PC1163-8460-XP DOT flightsafety DOT com>  <Pine DOT CYG DOT 4 DOT 58 DOT 0701051054010 DOT 280 AT PC1163-8460-XP DOT flightsafety DOT com>  <Pine DOT CYG DOT 4 DOT 58 DOT 0701051144030 DOT 2880 AT PC1163-8460-XP DOT flightsafety DOT com>  <20070105182234 DOT GC12776 AT calimero DOT vinschen DOT de>  <Pine DOT CYG DOT 4 DOT 58 DOT 0701051237090 DOT 2880 AT PC1163-8460-XP DOT flightsafety DOT com>  <20070105192302 DOT GD12776 AT calimero DOT vinschen DOT de> <20070110095345 DOT GL23638 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-IsSubscribed: yes
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/