Issue metadata
Sign in to add a comment
|
7.8%-12.7% regression in system_health.memory_desktop at 514097:514158 |
||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Nov 8 2017
📍 Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/1696f836f80000
,
Nov 8 2017
📍 Couldn't reproduce a difference. https://pinpoint-dot-chromeperf.appspot.com/job/1696f836f80000
,
Nov 8 2017
Simon: I don't understand the UI particularly, but it looks from https://pinpoint-dot-chromeperf.appspot.com/job/1696f836f80000 that there was a definite change in the value between the first and final run - should pinpoint have found a difference?
,
Nov 8 2017
+dtu Can you take a look?
,
Nov 8 2017
This is exactly the kind of case that will be better with variable repeat_count: https://github.com/catapult-project/catapult/issues/3964
,
Jan 11 2018
📍 Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/14b0baef040000
,
Jan 11 2018
📍 Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/14ad91d7040000
,
Jan 11 2018
Running a few more bisects now that the issue in #6 is closed. I'm a little worried there may be different culprits since one recovered and one did not.
,
Jan 12 2018
📍 Found a significant difference after 1 commit. https://pinpoint-dot-chromeperf.appspot.com/job/14b0baef040000 Enable SecondaryUiMd and ShowAllDialogsWithViewsToolkit on Mac By tapted@chromium.org · Mon Nov 06 13:45:29 2017 chromium @ 6b6e8fe1fcf17e0545c688d1bfda16d6f79fd97e Understanding performance regressions: http://g.co/ChromePerformanceRegressions
,
Jan 12 2018
https://crrev.com/6b6e8fe1fcf17e0545c688d1bfda16d6f79fd97e is mac specific. Is the regression mac specific? If so, please update the OS's effected below.
,
Jan 12 2018
from `chart memory:chrome:all_processes:reported_by_chrome:gpu:effective_size` I expect this is the same as Issue 763335 . Which was of a similar magnitude. Basically, the GPU process double-counts memory buffers when they are backed by native GPU Memory Buffers. (when they are not backed by native GPU Memory Buffers, they are just a handle to an OpenGL resource sitting in the GPU Memory buffer and so are not counted towards memory usage reported by telemetry). See https://chromium.googlesource.com/chromium/src/+/lkcr/docs/memory-infra/probe-cc.md#Other-Areas-of-Interest, which says, > Many of the allocations under CC are aliased with memory in the Browser or GPU process. When investigating CC memory it may be worth looking at the following external categories: > 1. GPU Process / GPU Category - All GPU resources allocated by CC have a counterpart in the GPU/GPU category. This includes GL Textures, buffers, and other GPU backed objects such as Native GPU Memory Buffers. > 2. Browser Process / GpuMemoryBuffer Category - Resources backed by Shared Memory GpuMemoryBuffers are allocated by the browser and will be tracked in this category. So this is not a regression in system memory. But merely Chrome mapping in a UI surface on screen for DMA. It is a bit weird that the "gmail" story would trigger SecondaryUi though -- maybe it's making a permissions request or something. I'll try to confirm that. But I don't think this is concerning.
,
Apr 3 2018
📍 Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/11d8a33f440000
,
Apr 3 2018
Most of the charts blaming this issue have a suspiciously equal perf improve soon after -- see attached. Started a pinpoint on that to see if that can be narrowed down. The tag on ChromiumPerf/chromium-rel-mac12/system_health.memory_desktop / memory:chrome:all_processes:reported_by_chrome:gpu:effective_size_avg / browse_media / comes right after Issue 780510 , which is due to Issue 781490 (Double counting of anonymous GL images in GPU process), which is the issue referred to in #c12 and diagnosed in Issue 763335 . The only slightly mysterious one is load_tools_dropbox . The earlier pinpoints were using load.tools.gmail -- I'll see if the dropbox one behaves any differently.
,
Apr 3 2018
📍 Pinpoint job started. https://pinpoint-dot-chromeperf.appspot.com/job/10528277440000
,
Apr 3 2018
📍 Found a significant difference after 1 commit. https://pinpoint-dot-chromeperf.appspot.com/job/10528277440000 Enable SecondaryUiMd and ShowAllDialogsWithViewsToolkit on Mac by tapted@chromium.org https://chromium.googlesource.com/chromium/src/+/6b6e8fe1fcf17e0545c688d1bfda16d6f79fd97e Understanding performance regressions: http://g.co/ChromePerformanceRegressions
,
Apr 3 2018
📍 Found a significant difference after 1 commit. https://pinpoint-dot-chromeperf.appspot.com/job/11d8a33f440000 [Password Manager] Determine username and password elements based on user input by kolos@chromium.org https://chromium.googlesource.com/chromium/src/+/bc80bd0bc8122c66c7a13c108137e2643754980e Understanding performance regressions: http://g.co/ChromePerformanceRegressions
,
Apr 3 2018
So #c17 is the perf improvement - and it supports the suspicion I had in #c12 that the "gmail" story was triggering some secondary UI. (and it's likely that secondary Ui is the password manager). and per Issue 781490 and Issue 763335 it's most likely that this is just the double-counting of DMA GPU buffers. So I don't think there's a real regression here. (These UI GPU buffers are also lazily created and reused). It is annoying that these stories may or may not surface secondary UI - I don't think they are designed for that - but they should stabilise again. Closing this WontFix, but if anyone thinks there are other avenues to explore, please let me know. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by 42576172...@developer.gserviceaccount.com
, Nov 8 2017