I'm quite sure it is jemalloc. I failed miserably by not over-communicating
this checkin. My apologies to all that I have inconvenience.
We have just this week identified a number of misteps in our use of
TCMalloc. I think that we can eventually reach an excellent result with
TCMalloc... and we had a few fixes... but we also wanted to be able to talk
more precisely about how things contrast with jemalloc (as folks ask us why
we're looking so intently at tcmalloc).
If folks are cool with it, it might be interesting to push the dev build
with this in place. JEMalloc appears to be very conservative in its memory
usage, but doesn't get the speed we've seen with TCMalloc. We can already
see some specific areas where the current (checked in) incarnation of
TCMalloc stumbles (example: today, TCMalloc never decommits memory in the
browser process... yeah... that's just a bug... but I was wondering how much
it hurt... and a switch to jemalloc would instantly provide a temporary
fix). It may be interesting to see the response on the dev channel to this
temporary change.
Side benefits include some feedback on crashers, as each allocator
illuminates a different set of corruption problems ("if" we have any :-) ).
Do other folks agree it would be interesting to see a dev build go out with
this in place??
Thanks,
Jim
On Thu, Oct 1, 2009 at 8:46 AM, Mike Belshe <mbel...@google.com> wrote:
> Probably caused by jemalloc. Jim was experimenting with the idea of
> getting some dev-channel data from using jemalloc as opposed to tcmalloc.
> I'm not surprised there was a perf delta, but I am surprised by how much.
> The DOM benchmark in this test dropped by 8%. Several other benchmarks
> took similar hits.
> http://build.chromium.org/buildbot/perf/vista-release-dual-core/dom_perf/report.html?history=150
>
> http://build.chromium.org/buildbot/perf/xp-release-single-core/bloat-http/report.html?history=150
>
> But the memory test does use about 10% less RAM with jemalloc (as
> predicted):
>
> http://build.chromium.org/buildbot/perf/vista-release-dual-core/memory/report.html?history=150
> And almost all memory tests got better:
>
> http://build.chromium.org/buildbot/perf/dashboard/overview.html?graph=vm_peak_b
>
> So: tcmalloc == faster; jemalloc == smaller. We knew this.
>
> I think we should probably back out jemalloc - the perf hit is non-trivial,
> and the memory we can improve with other, upcoming tcmalloc work. Jim - how
> badly do you want jemalloc dev-channel data? I'm not sure it will buy us a
> lot other than what we already know.
>
> Mike
>
>
> On Thu, Oct 1, 2009 at 8:29 AM, Darin Fisher <da...@chromium.org> wrote:
>
>> Note: my change was reverted for other reasons.-Darin
>>
>> On Thu, Oct 1, 2009 at 7:58 AM, Chase Phillips <ch...@chromium.org>wrote:
>>
>>> Hey everyone,
>>> A performance regression has appeared on the XP Perf bot in the morejs
>>> page cycler. Along with turning XP Perf red, the perf regression system
>>> notified me via email (forwarded below). The page load regression is about
>>> 30ms. There's a similar regression in the moz page cycler. Here's a link
>>> to the XP Perf dashboard to see the morejs regression:
>>>
>>> http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=50
>>>
>>> The interesting revisions between r27704 and r27710 are:
>>>
>>> r27705 - darin - Move various methods from glue to
>>> api.<http://src.chromium.org/viewvc/chrome?view=rev&revision=27705>
>>> r27708 - jar - Set JEMalloc as the default allocator (instead of
>>> TCMalloc).<http://src.chromium.org/viewvc/chrome?view=rev&revision=27708>
>>> r27710 - thestig - Disable CheckSvnModifiedDirectories for
>>> now.<http://src.chromium.org/viewvc/chrome?view=rev&revision=27710>
>>>
>>> @jar: Not meaning to pick on you, but my guess is the JEMalloc change is
>>> the cause. Did you expect a page load regression from your change?
>>>
>>> PS If you haven't heard of this perf regression system, don't worry --
>>> it's a new tool in Chromium's toolbox. Email and docs describing it will be
>>> sent soon.
>>>
>>> Thanks,
>>> Chase
>>>
>>> ---------- Forwarded message ----------
>>> From: <build...@chromium.org>
>>> Date: Thu, Oct 1, 2009 at 7:15 AM
>>> Subject: buildbot failure in Chromium on XP Perf, revision 27719
>>> To: c...@google.com
>>>
>>>
>>> http://build.chromium.org/buildbot/waterfall/
>>>
>>> Perf alert on "XP Perf": page_cycler_morejs
>>>
>>>
>>> http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414
>>>
>>> Revision: 27719
>>> Blame list: ida...@google.com
>>>
>>> XP Perf
>>> Build
>>> 9414<http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414>
>>> svnkill
>>> stdio<http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell/logs/stdio>
>>> update
>>> scripts
>>> stdio<http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_2/logs/stdio>
>>> taskkill
>>> stdio<http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/shell_3/logs/stdio>
>>> update
>>> stdio<http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/gclient/logs/stdio>
>>> extract
>>> build
>>> stdio<http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/extract%20build/logs/stdio>
>>> Start
>>> Crash Handler
>>> stdio<http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/Start%20Crash%20Handler/logs/stdio>
>>> uploading
>>> perf_expectations.json page_cycler_moz
>>>
>>> IO_b_b: 41.8k (39.7k)
>>> IO_b_b_extcs1: 41.8k
>>> IO_b_r: 6.74k (6.0k)
>>> IO_b_r_extcs1: 6.62k
>>> IO_op_b: 51.6k (51.8k)
>>> IO_op_b_extcs1: 55.0k
>>> IO_op_r: 25.3k (28.3k)
>>> IO_op_r_extcs1: 25.2k
>>> t: 1.08k (1.19k)
>>> t_extcs1: 1.25k
>>> vm_pk_b: 8.24M (17.0M)
>>> vm_pk_b_extcs1: 9.68M
>>> vm_pk_r: 83.2M (72.9M)
>>> vm_pk_r_extcs1: 85.6M
>>> ws_pk_b: 20.0M (24.8M)
>>> ws_pk_b_extcs1: 21.4M
>>> ws_pk_r: 75.3M (73.7M)
>>> ws_pk_r_extcs1: 80.5M
>>>
>>> stdio<http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_moz/logs/stdio>
>>> [results<http://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=150>
>>> ] page_cycler_morejs
>>>
>>> PERF_REGRESS: times/t
>>> IO_b_b: 19.2k (17.5k)
>>> IO_b_b_extcs1: 19.3k
>>> IO_b_r: 475 (243)
>>> IO_b_r_extcs1: 475
>>> IO_op_b: 20.3k (19.5k)
>>> IO_op_b_extcs1: 23.4k
>>> IO_op_r: 9.56k (4.17k)
>>> IO_op_r_extcs1: 9.56k
>>> t: 1.4k (1.31k)
>>> t_extcs1: 1.44k
>>> vm_pk_b: 7.06M (16.1M)
>>> vm_pk_b_extcs1: 8.49M
>>> vm_pk_r: 8.28M (18.0M)
>>> vm_pk_r_extcs1: 8.3M
>>> ws_pk_b: 19.0M (23.8M)
>>> ws_pk_b_extcs1: 20.4M
>>> ws_pk_r: 12.6M (21.6M)
>>> ws_pk_r_extcs1: 12.6M
>>>
>>> stdio<http://build.chromium.org/buildbot/waterfall/builders/XP%20Perf/builds/9414/steps/page_cycler_morejs/logs/stdio>
>>> [results<http://build.chromium.org/buildbot/perf/xp-release-dual-core/morejs/report.html?history=150>
>>> ]
>>>
>>> Changed by: *ida...@google.com*
>>> Changed at: *Thu 01 Oct 2009 07:00:09*
>>> Branch: *src*
>>> Revision: *27719*
>>>
>>> Changed files:
>>>
>>> - *chrome/browser/privacy_blacklist/blocked_response.cc*
>>> - *chrome/browser/privacy_blacklist/blocked_response.h*
>>> - *chrome/browser/resources/privacy_blacklist_block.html*
>>> - *chrome/browser/renderer_host/resource_dispatcher_host.cc*
>>> - *chrome/browser/renderer_host/resource_dispatcher_host.h*
>>>
>>> Comments:
>>>
>>> Privacy Blacklist Unblock
>>>
>>> Summary
>>> -------
>>>
>>> Mostly implemented the unblocking for visual resources for the Privacy
>>> Blacklist.
>>> Merging now before I leave. Eveything here only has effect if the
>>> --privacy-blacklist
>>> flag specifies a Privacy Blacklist.
>>>
>>> Detailed Changes
>>> ----------------
>>>
>>> [chrome/browser/resources/privacy_blacklist.html]
>>>
>>> - Replaced the about:blank place-holder with variable to set the unblock
>>> link.
>>>
>>> - Open the Privacy Blacklist provider page in a new tab. This works around
>>> an
>>> issue where such request for a full-page (rather than a sub-resource) gets
>>> blocked indefinitely.
>>>
>>> [chrome/browser/render_host/resource_dispatcher_host.h]
>>>
>>> - Added a BlockedResponse member which is now a class rather than a
>>> namespace,
>>> see below for more information.
>>>
>>> [chrome/browser/render_host/resource_dispatcher_host.cc]
>>>
>>> - Generate headers for the blocked response to redirect to the
>>> chrome-blocked URL
>>> which prevents an enclosing page from reading the URL of the unblock
>>> link. This
>>> was suggested by Darin to avoid scripted bypassing of blocked contents.
>>>
>>> - Recover the original URL for blocked content, in order to fetch it during
>>> unblocking.
>>>
>>> - Do not create CrossSiteResourceHandler when an unblocked link is
>>> requested.
>>> Otherwise the request never resumes as the blocked page never gets closed
>>> since it is not a real page.
>>>
>>> [chrome/browser/privacy_blacklist/blocked_response.cc]
>>>
>>> - Defined chrome-block and chrome-unblock URL schemes. The block scheme is
>>> used
>>> to return the blocked response. The unblock scheme is used request a
>>> blocked
>>> resource's URL without being intercepted by the Privacy Blacklist.
>>>
>>> - Defined a hash function for a blocked resource as its address in memory.
>>> Function to reverse the hash is therefore trivial.
>>>
>>> - Added a function to return headers for a blocked response.
>>>
>>> - Added a function to generate a block URL from a requested one.
>>>
>>> - Added a function to get an unblock URL from a requested one.
>>>
>>> - Added a function to return the original URL for a blocked one.
>>>
>>> [chrome/browser/privacy_blacklist/blocked_response.h]
>>>
>>> - Made the BlockedResponse namespace into a class.
>>>
>>> - Created a member set to keep all the blocked resources URL.
>>>
>>> BUG=16932
>>> TEST=none
>>> TBR=darin
>>>
>>> Review URL: http://codereview.chromium.org/252001
>>>
>>>
>>>
>>
>> >>
>>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
