On Tue, Oct 30, 2012 at 04:35:02PM +0100, Mike Hommey wrote: > On Fri, Oct 26, 2012 at 06:10:13PM +0200, Mike Hommey wrote: > > > > > 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. > > Some more data: all non-unmapped chunks *are* used to some extent. The > following is a dump of the number of requested and usable bytes in each > chunk ; that's 18M spread across 600M... that sounds like a really bad > case of fragmentation.
BTW, it does seem to grow forever: I went up to 1.3GB with more iterations before stopping. Mike _______________________________________________ jemalloc-discuss mailing list [email protected] http://www.canonware.com/mailman/listinfo/jemalloc-discuss
