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 fi
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
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. Th
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 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?
> >
> >
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.
whi
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, memorize
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 u
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 compa
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 http://blogs.msdn.com/old
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 h
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
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 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 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
http://cygwin.com/ml/cygwin
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 s
On Jan 10 22:38, Christopher Layne wrote:
> > 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 a
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
> 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
vali
> 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 subseq
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 request
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 th
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 sh
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
> > getsystemp
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 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 t
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
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 sh
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 p
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 beh
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 histor
> 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 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
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 succes
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(
(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 fa
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 b
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_RESER
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
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 n
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 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, 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 real
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
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
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 its
> significance before.
>
> I understa
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 E
On Fri, Jan 05, 2007 at 08:17:51AM -0800, Christopher Layne wrote:
>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
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: http://cygwin.com/ml
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
> significanc
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 syste
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*,
>
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
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 notice
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
> mm
55 matches
Mail list logo
