On Thu, Jan 18, 2007 at 06:18:52PM +0100, Corinna Vinschen wrote:
Right, it's an optimization problem rather than a bug. Patches
welcome, but I've put it on my TODO list, too.
I have applied a patch to CVS which calls fstat early, at the spot where
GetFileSize got called so far. The stat
On Jan 19 07:41, Christopher Layne wrote:
Thanks for fixing this. I also noticed these when reading through the code.
Another area for extremely small optimization is to just cache the pagesize.
I notice a *lot* of calls to getpagesize(), when I can't really see the
pagesize changing within a
On Thu, 18 Jan 2007, Corinna Vinschen wrote:
I have applied a patch to CVS which calls fstat early, at the spot where
GetFileSize got called so far. The stat structure is then propagated to
subsequent function calls and used there. This should reduce the fstat
calls to exactly one per file
On Jan 17 13:42, Brian Ford wrote:
On Wed, 17 Jan 2007, Corinna Vinschen wrote:
On Jan 16 17:28, Brian Ford wrote:
PS: In an strace of this, I see three fstat64s called from within a
single mmap64. Do you know where they all are, and if two should be
optimized away?
There's only
On Jan 18 10:14, Corinna Vinschen wrote:
On Jan 17 13:42, Brian Ford wrote:
mmap.cc:1203 mmap64():
map_list = mmapped_areas.get_list_by_fd (fd);
mmap.cc:982 mmap_worker():
if (!(map_list = mmapped_areas.get_list_by_fd (fd))
mmap.cc:983 mmap_worker():
!(map_list =
On Jan 16 17:28, Brian Ford wrote:
On Wed, 10 Jan 2007, Brian Ford wrote:
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,
On Wed, 17 Jan 2007, Corinna Vinschen wrote:
On Jan 16 17:28, Brian Ford wrote:
PS: In an strace of this, I see three fstat64s called from within a
single mmap64. Do you know where they all are, and if two should be
optimized away?
There's only one such call in list::set.
which is
On Wed, 10 Jan 2007, Brian Ford wrote:
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
About the reason why the last 64K just before 2GB can't be used in
Windows, I'll refer you to this post in The Old New Thing blog by
Raymond Chen, who regularly discusses such obscure compatibility issues.
See http://blogs.msdn.com/oldnewthing/archive/2003/10/08/55239.aspx.
(Short answer: it
On 15 January 2007 14:03, Pierre Baillargeon wrote:
About the reason why the last 64K just before 2GB can't be used in
Windows, I'll refer you to this post in The Old New Thing blog by
Raymond Chen, who regularly discusses such obscure compatibility issues.
See
On 15 January 2007 14:48, Dave Korn wrote:
On 15 January 2007 14:03, Pierre Baillargeon wrote:
About the reason why the last 64K just before 2GB can't be used in
Windows, I'll refer you to this post in The Old New Thing blog by
Raymond Chen, who regularly discusses such obscure
On Thu, Jan 11, 2007 at 10:46:48AM +0100, Corinna Vinschen wrote:
This works on my machine now. So previously why was the former method
failing, do you think?
Er... haven't we discussed this at great lengths in this thread?
Yes, but did we ever establish a reason that was actually solid
On Jan 13 00:22, Christopher Layne wrote:
The real question I have is why was what *should* have worked, not working?
That has been answered immediately in the replies:
http://cygwin.com/ml/cygwin/2007-01/msg00093.html
http://cygwin.com/ml/cygwin/2007-01/msg00095.html
On Sat, Jan 13, 2007 at 11:25:08AM +0100, Corinna Vinschen wrote:
On Jan 13 00:22, Christopher Layne wrote:
The real question I have is why was what *should* have worked, not working?
That has been answered immediately in the replies:
http://cygwin.com/ml/cygwin/2007-01/msg00093.html
On Sat, Jan 13, 2007 at 06:29:18AM -0800, Christopher Layne wrote:
On Sat, Jan 13, 2007 at 11:25:08AM +0100, Corinna Vinschen wrote:
On Jan 13 00:22, Christopher Layne wrote:
The real question I have is why was what *should* have worked, not
working?
That has been answered immediately in the
On Jan 10 22:44, Christopher Layne wrote:
On Jan 10 09:37, Brian Ford wrote:
Yes, this fixes my STC and the application from which it was derived.
Thanks.
BTW: a couple of things:
1. Is there a possibility of another application or thread reserving that
just alloc/free'd area right
On Jan 5 20:23, Corinna Vinschen wrote:
On Jan 5 12:42, Brian Ford wrote:
On Fri, 5 Jan 2007, Corinna Vinschen wrote:
So, it does indeed look taken.
Too bad.
Actually this shows a problem in the mmap implementation with respect to
MEM_TOP_DOWN. I think, what mmap should actually
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
On Jan 10 09:37, Brian Ford wrote:
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
Since overmapping doesn't work on Windows, unfortunately, 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
On Jan 10 09:37, Brian Ford wrote:
Yes, this fixes my STC and the application from which it was derived.
Thanks.
BTW: a couple of things:
1. Is there a possibility of another application or thread reserving that
just alloc/free'd area right after using it to obtain (at that time) a
valid
On Sun, Jan 07, 2007 at 11:58:44AM +0100, Corinna Vinschen wrote:
Lots of comments throughout the file...
Unfortunately the code-path is less than clear to follow. This may be
a matter of opinion but it's fairly complex and looks to have history in
it.
In the 2nd strace, I changed the mmap
Also, check this out:
http://blogs.msdn.com/oldnewthing/archive/2003/10/08/55239.aspx
Meant to also include:
http://support.microsoft.com/kb/125713
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation:
On Jan 9 01:04, Christopher Layne wrote:
On Sun, Jan 07, 2007 at 11:58:44AM +0100, Corinna Vinschen wrote:
Lots of comments throughout the file...
Unfortunately the code-path is less than clear to follow. This may be
a matter of opinion but it's fairly complex and looks to have history in
Real quick here and I'll follow up tomorrow. I don't get SIGSEGV
in my application ever. I get an error back from mmap saying it
cannot allocate memory when i'm simply trying to open a small
file! The original events ere posted up in that first part of
the strace - which is unmodified original
On Jan 9 04:04, Christopher Layne wrote:
Real quick here and I'll follow up tomorrow. I don't get SIGSEGV
in my application ever. I get an error back from mmap saying it
cannot allocate memory when i'm simply trying to open a small
file! The original events ere posted up in that first part
On Tue, Jan 09, 2007 at 01:23:58PM +0100, Corinna Vinschen wrote:
Yes, I know. I never said you get a SEGV from mmap, but you get the
SEGV in your testapp. That's what I'm referring to. mmap fails (just
fails, no SEGV, yes, I know) because it fails to generate the filler
pages. This
On Tue, Jan 09, 2007 at 12:56:43PM +0100, Corinna Vinschen wrote:
Okay, I understand where you're coming from. Where I'm coming from is that
it
is difficult to generate a test case that actually demonstrates the issue
outside of the scope of my application. Suffice to say, I do see the
On Jan 7 11:51, Corinna Vinschen wrote:
On Jan 5 15:15, Brian Ford wrote:
On Fri, 5 Jan 2007, Corinna Vinschen wrote:
overmap? -v please?
Posix symantics: mmap fixed region x, mmap fixed region y which is a
subregion of x where y replaces x's mapping.
AFAIK that doesn't work
On Tue, 9 Jan 2007, Christopher Layne wrote:
extern C size_t
getpagesize ()
{
if (!system_info.dwPageSize)
GetSystemInfo (system_info);
return (size_t) system_info.dwAllocationGranularity;
}
size_t
getsystempagesize ()
{
if (!system_info.dwAllocationGranularity)
On Jan 9 09:33, Brian Ford wrote:
On Tue, 9 Jan 2007, Christopher Layne wrote:
extern C size_t
getpagesize ()
{
if (!system_info.dwPageSize)
GetSystemInfo (system_info);
return (size_t) system_info.dwAllocationGranularity;
}
size_t
getsystempagesize ()
{
if
On Jan 5 15:15, Brian Ford wrote:
On Fri, 5 Jan 2007, Corinna Vinschen wrote:
overmap? -v please?
Posix symantics: mmap fixed region x, mmap fixed region y which is a
subregion of x where y replaces x's mapping.
AFAIK that doesn't work on Windows. But, somebody has to test it(tm).
On Jan 6 07:45, Christopher Layne wrote:
(warning a bunch of strace, scroll wide).
So I haven't been able to totally nail anything down on this issue due
to the incredible complexity of Cygwin's mmap interface.
Lots of comments throughout the file...
This is 2 simple mmap()s in
(warning a bunch of strace, scroll wide).
So I haven't been able to totally nail anything down on this issue due
to the incredible complexity of Cygwin's mmap interface.
This is 2 simple mmap()s in succession, 1st is 46121 bytes, 2nd is 111 bytes.
Both opened read/write. The second mmap always
On Jan 4 17:17, Brian Ford wrote:
$ uname -a
CYGWIN_NT-5.1 PC1163-8460-XP 1.7.0(0.161/4/2) 2007-01-04 15:51 i686
unknown unknown Cygwin
$ ./mmaptest.exe
CloseHandle(fh_disk_file.get_handle ()) 0x738 failed void* mmap64(void*,
size_t, int, int, int, _off64_t):1275, Win32 error 6
mmap:
While this also passes on mine - mmap has been performing
strangely for me also (since around November snapshots).
SPECIFICALLY: After the allocate downwards change was done,
mmap calls started returning ENOMEM (Cannot allocate memory)
where they worked before just fine. I specifically noticed
Christopher Layne, le Fri 05 Jan 2007 08:02:15 -0800, a écrit :
I will also say this, I only get ENOMEM if mmap() tries to
map a file LESS than the system page size.
Not sure about the cygwin state, but at least on the Linux/Posix side,
mmap() is not supposed to be able to work with a smaller
On Fri, 5 Jan 2007, Corinna Vinschen wrote:
On Jan 4 17:17, Brian Ford wrote:
$ uname -a
CYGWIN_NT-5.1 PC1163-8460-XP 1.7.0(0.161/4/2) 2007-01-04 15:51 i686
unknown unknown Cygwin
$ ./mmaptest.exe
CloseHandle(fh_disk_file.get_handle ()) 0x738 failed void* mmap64(void*,
size_t, int,
mmap() is supposed to zero-fill, not refuse to map when len
is less than the system page size. I have never ever seen
mmap() fail to map less than page size on any typical Posix
system.
The system shall always zero-fill any partial page at the end
of an object. Further, the
On Fri, Jan 05, 2007 at 10:17:19AM -0600, Brian Ford wrote:
Ok, after further investigation, this is a /3GB boot.ini flag interaction.
Unfortunately, this is a critical flag for our application, so all our
machines are configured this way. That is why I failed to realize its
significance
Christopher Layne, le Fri 05 Jan 2007 08:17:51 -0800, a écrit :
mmap() is supposed to zero-fill, not refuse to map when len
is less than the system page size.
Ah oops sorry, that's the addr parameter which needs to always be
page-aligned.
Samuel
--
Unsubscribe info:
On Fri, Jan 05, 2007 at 11:34:36AM -0500, Christopher Faylor wrote:
MEM_TOP_DOWN
0x10 Allocates memory at the highest possible address.
If there were any kind of simple arithmetic bug behind mmap()'s
scenes (such as computing space to zero-fill, etc. etc.) I would
think ENOMEM would
On Fri, Jan 05, 2007 at 10:55:09AM -0600, Brian Ford wrote:
On Fri, 5 Jan 2007, Brian Ford wrote:
Ok, after further investigation, this is a /3GB boot.ini flag
interaction. Unfortunately, this is a critical flag for our
application, so all our machines are configured this way. That is why
I
On Fri, 5 Jan 2007, Christopher Faylor wrote:
On Fri, Jan 05, 2007 at 10:55:09AM -0600, Brian Ford wrote:
One more tidbit before I have time to find the real problem. Compiling
the test case with -Wl,large-address-aware makes the test pass on a
/3GB system.
Does that mean that this is a
On Fri, 5 Jan 2007, Brian Ford wrote:
On Fri, 5 Jan 2007, Brian Ford wrote:
Ok, after further investigation, this is a /3GB boot.ini flag interaction.
Unfortunately, this is a critical flag for our application, so all our
machines are configured this way. That is why I failed to realize
On Jan 5 11:52, Brian Ford wrote:
Here is an interesting strace comparison:
Non-/3GB:
4978 26688 [main] mmaptest 2284 MapViewNT: 7FFA =
NtMapViewOfSection (h:6EC, addr:0, len:28237, off:0, protect:80, type:0)
[snip]
60 27113 [main] mmaptest 2284 MapViewNT: 7FFA7000 =
On Fri, 5 Jan 2007, Corinna Vinschen wrote:
In the failing case this should still work, since 0x7fff7000 + 0x9000
(36864 dec) == 0x8000, so the mapping should fit into the usual 2
Gig address space. Why Windows fails to do it, I have no idea. The
error code 487 means invalid address
On 05 January 2007 18:42, Brian Ford wrote:
On Fri, 5 Jan 2007, Corinna Vinschen wrote:
In the failing case this should still work, since 0x7fff7000 + 0x9000
(36864 dec) == 0x8000, so the mapping should fit into the usual 2
Gig address space. Why Windows fails to do it, I have no idea.
On 05 January 2007 18:47, Dave Korn wrote:
On 05 January 2007 18:42, Brian Ford wrote:
On Fri, 5 Jan 2007, Corinna Vinschen wrote:
In the failing case this should still work, since 0x7fff7000 + 0x9000
(36864 dec) == 0x8000, so the mapping should fit into the usual 2
Gig address
On Jan 5 12:42, Brian Ford wrote:
On Fri, 5 Jan 2007, Corinna Vinschen wrote:
So, it does indeed look taken.
Too bad.
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
On Fri, 5 Jan 2007, Corinna Vinschen wrote:
overmap? -v please?
Posix symantics: mmap fixed region x, mmap fixed region y which is a
subregion of x where y replaces x's mapping.
--
Brian Ford
Lead Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
the
51 matches
Mail list logo
