[7ca0fdf] Disable munmap() if it causes VM map holes
mh+jemalloc at glandium.org
Mon Apr 16 14:19:03 PDT 2012
On Mon, Apr 16, 2012 at 01:59:39PM -0700, Jason Evans wrote:
> On Apr 16, 2012, at 1:19 PM, Mike Hommey wrote:
> > On Mon, Apr 16, 2012 at 12:07:58PM -0700, Jason Evans wrote:
> >> On Apr 16, 2012, at 8:08 AM, Mike Hommey wrote:
> >>> I noticed something "interesting" with the test for VM map holes:
> >>> If I compile it manually, it fails:
> >>> Hoped for 0x7f835133d000, got 0x7f8350b3d000
> >>> 0x7f835173d000..0x7f835133d000..0x7f8350f3d000..0x7f835073d000..0x7f8350b3d000
> >>> Apparently, this happens when *not* linking libm to the testcase.
> >>> It also does happen when linking libm and some other library
> >>> (tried pthread and stdc++).
> >> What OS is this on? The test should fail on Linux, but not OS X or
> >> FreeBSD. Linux has a VM map management quirk (on at least x86)
> >> that causes accumulation of VM map holes under normal operation.
> > Linux x64. Kernel 3.2.
> > So, you are saying that this error is the "expected" behaviour,
> > except I actually don't get it under "normal" conditions (those of
> > configure.ac)
> Hmm, maybe those extra libraries are creating another hole that's
> preventing the initial series of mmap calls from getting contiguous
> memory. Can you move the two fprintf calls ("Hoped for …" and the
> next one) out of the conditional block and pull the resulting output
> from config.log? That'll help me understand what's happening so that
> I can refine the test. (I can't reproduce the problem on the Linux
> machines I'm using).
Hoped for 0x7f4d5d7d6000, got 0x7f4d5cfd6000
Hoped for 0x7f82e5237000, got 0x7f82e5237000
But anyways, why do you want to do a configure run test when you know
the result you want?
More information about the jemalloc-discuss