Memory usage regression

Mike Hommey mh+jemalloc at glandium.org
Fri Oct 26 09:10:13 PDT 2012


On Fri, Oct 26, 2012 at 05:08:24PM +0200, Mike Hommey wrote:
> On Fri, Oct 26, 2012 at 05:03:35PM +0200, Mike Hommey wrote:
> > On Fri, Oct 26, 2012 at 11:45:32AM +0200, Mike Hommey wrote:
> > > Some more data:
> > > 
> > > http://i.imgur.com/3Q2js.png
> > > This is zooming on the big bump at the beginning of iteration 2. Looking
> > > at the corresponding allocation log, this corresponds to > 1MB
> > > allocations with memalign, but turning them into mallocs doesn't change
> > > the result, so it's not a memalign problem.
> > > 
> > > Looking more globally at the data, there is /some/ correlation with >
> > > 1MB allocations, but occasionally, 128KB allocations do trigger the same
> > > behaviour, as well as 64KB. One interesting fact is that it's only a
> > > limited subset of these big allocations that trigger this. The vast
> > > majority of them don't.
> > > 
> > > For reference, the unzoomed graph looks like this:
> > > http://i.imgur.com/PViYm.png
> > 
> > I rediscovered --enable-munmap, and tried again with that, thinking it
> > could be related, and it did change something, but it's still growing:
> > http://i.imgur.com/lWzhG.png
> 
> Needless to say, the increases I was observing closely on the the zoomed
> graph without a matching decrease was entirely due to munmap. Now I need
> to find the remainder...

I tested size class independently, and none would cause the VM leak
alone. Combining small and large classes do, but large + huge or small +
huge don't.

Mike



More information about the jemalloc-discuss mailing list