|
From: Christian P. <tr...@ge...> - 2005-07-20 15:11:22
|
On Wednesday 20 July 2005 16:54, Tom Hughes wrote: > In message <200...@ge...> > Christian Parpart <tr...@ge...> wrote: > > On Wednesday 20 July 2005 15:39, Nicholas Nethercote wrote: > >> The mmap and munmap calls are very big -- 61680GB and 69390GB > >> respectively. The fact that it happens before the usage message shows > >> this is happening very early. I guess these mmap/munmap calls are from > >> the start-up padding, but then the question is why isn't this causing > >> problems on other AMD64 systems? > > > > I'm having 2GB RAM, and 1GB swap. maybe this matters? > > Besides, why the hell is valgrind m[un]mapping such a huge space (I even > > haven't that much RAM et al) > > It's mapping it to stop anything else being given that part of the > address space - it is how valgrind controls where the OS puts stuff. > > Note that the memory will never be touched so it is an entirely > virtual concept and how much memory or swap you should not matter > in the slightest. That is why we pass the NORESERVE flag to indicate > that the kernel doesn't need to reserve any swap to back the mapping. Ah, I seem to understand; however, I now start wondering why the kernel tak= es=20 so long there. Might this be a kernel bug (regarding performance)? Although - I'm just curious - how are you thinking of working around such=20 (mis)behaviors when not using m[un]map? And why am I (obviousely) the only one having this problem? Regards, Christian Parpart. |