On Thu, Oct 1, 2009 at 11:27 AM, Scott Hess <sh...@chromium.org> wrote:
> I think we should be willing to take a temporary performance hit on the dev
> channel in the interests of generating data which will eventually improve
> stability.
> Could we set jemalloc on selected renderer processes? I realize that
> wouldn't necessarily only impact the target domains, but it might be better
> than making the change global.
>
It can be set by a per-process environment variable. So... yes, this could
be done. Mix-and-match allocators might be a little strange for anything
other than debugging/testing.
Mike
>
> -scott
>
>
> On Thu, Oct 1, 2009 at 10:47 AM, Jim Roskind <j...@chromium.org> wrote:
>
>> 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
-~----------~----~----~----~------~----~------~--~---
