On Wed, Feb 18, 2015 at 07:15:11PM +0900, Mike Hommey wrote: > On Wed, Feb 18, 2015 at 06:34:26PM +0900, Mike Hommey wrote: > > On Wed, Feb 04, 2015 at 11:54:32AM +0900, Mike Hommey wrote: > > > On Wed, Feb 04, 2015 at 07:51:17AM +0900, Mike Hommey wrote: > > > > Hi, > > > > > > > > I've been tracking a startup time regression in Firefox for Android when > > > > we tried to switch from mozjemalloc (memory refresher: it's derived from > > > > jemalloc 0.9) to mostly current jemalloc dev. > > > > > > > > It turned out to be https://github.com/jemalloc/jemalloc/pull/192 > > > > > > *sigh* and sadly, this doesn't fix it all :( > > > > So, it /might/ be related to the size classes. I don't have all results > > yet, but it looks like I'm getting good results with #192, > > --with-lg-quantum=4, --with-lg-tiny-min=2 and replacing size2index, > > index2size and s2u so that jemalloc3 uses the same size classes as > > mozjemalloc (IOW, a very bastardized jemalloc3) > > > > If that happens to be true, I'll dig deeper as to what particular size > > classes changes are making a difference. > > And with more results coming in, it's starting to look like it was a red > herring :( > The comment about the size classes well above the chunk size still stands, > though.
... and we do have regressions on x86 as well, on, presumably, allocation intensive workflows. We also have a RSS regression on Windows that I'll have to look at more closely. Mike _______________________________________________ jemalloc-discuss mailing list jemalloc-discuss@canonware.com http://www.canonware.com/mailman/listinfo/jemalloc-discuss
