munmap slowness; IsBadReadPtr considered harmful
Tue Feb 24 00:04:00 GMT 2004
On Fri, 20 Feb 2004, Brian Ford wrote:
> Using strace, I traced a severe performance problem with one of our apps
> to munmap. That call was taking an extrodinarily long time to complete,
> especially if the file to be unmapped was on a network drive.
> By adding more strace log messages, I narrowed the problem down to the
> IsBadReadPtr check for a vaild address range. Further more, using
> Sysinternals filemon, I found that IsBadReadPtr appears to be faulting in
> every non-resident page in the range. That obviously explains the slow
> down, especially for files on network drives.
> So, the question is, does anyone have any idea how to perform the validity
> check without faulting in the entire address range we're about to dump?
Ok, no response. That means either:
1.) No one knows an alternative way to do the check.
2.) No one cares that munmap has this overhead.
3.) No one believes me, or they can't reproduce the problem.
4.) No one likes me :( ...
Ok, now back on topic :).
FWIW, the following replacement for IsBadReadPtr appears to have the
same functionality without the associated page fault overhead.
static inline bool
is_addr_valid (void *addr, size_t len)
for (end = (char *) addr + len; addr < end;
addr = (char *) addr + mbuf.RegionSize)
if (!VirtualQuery (addr, &mbuf, sizeof mbuf))
syscall_printf ("VirtualQuery (addr %x) %E", addr);
So, any comments about the function above, where to put it, or what to
I see in the archives that the IsBadXPtr vs. VirtualQuery debate has
happened before in different contexts. It seams to me that VirtualQuery
wins here hands down, though.
Please, if you have the time, give me just a little feedback so I can cook
up a "formal" patch. Thanks.
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
More information about the Cygwin-developers