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 _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
