Issue metadata
Sign in to add a comment
|
1%-3.7% regression in memory.top_10_mobile at 461424:461495 |
||||||||||||||||||||
Issue descriptionSee the link to graphs below.
,
Apr 5 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8983144588013961888
,
Apr 5 2017
=== BISECT JOB RESULTS === Bisect failed for unknown reasons Please contact the team (see below) and report the error. Bisect Details Configuration: android_nexus7_perf_bisect Benchmark : memory.top_10_mobile Metric : memory:chrome:all_processes:reported_by_os:gpu_memory:proportional_resident_size_avg/background/after_https_m_facebook_com_rihanna Please refer to the following doc on diagnosing memory regressions: https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md To Run This Test src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests memory.top_10_mobile Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8983144588013961888 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5810239737167872 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Speed>Bisection. Thank you!
,
Apr 11 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8982576165985402624
,
Apr 13 2017
,
Apr 13 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8982417421156684032
,
Apr 13 2017
=== Auto-CCing suspected CL author pkotwicz@chromium.org === Hi pkotwicz@chromium.org, the bisect results pointed to your CL, please take a look at the results. === BISECT JOB RESULTS === Perf regression found with culprit Suspected Commit Author : pkotwicz Commit : 98068764b24c38a5f23049fab6d1412271fceee5 Date : Mon Apr 03 16:08:00 2017 Subject: Enable perf bots to test WebAPK variations experiment Bisect Details Configuration: android_nexus7_perf_bisect Benchmark : memory.top_10_mobile Metric : memory:chrome:all_processes:reported_by_os:gpu_memory:proportional_resident_size_avg/background/after_https_m_facebook_com_rihanna Change : 3.58% | 14595413.3333 -> 15118336.0 Revision Result N chromium@461440 14595413 +- 61485.5 6 good chromium@461442 14594731 +- 62231.3 6 good chromium@461443 14585856 +- 0.0 6 good chromium@461444 15215275 +- 588020 6 bad <-- chromium@461447 15116971 +- 124866 6 bad chromium@461454 15106731 +- 73366.8 6 bad chromium@461468 15117653 +- 82005.3 6 bad chromium@461495 15118336 +- 122607 6 bad Please refer to the following doc on diagnosing memory regressions: https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md To Run This Test src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests memory.top_10_mobile Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8982417421156684032 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5232917560688640 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Speed>Bisection. Thank you!
,
Apr 19 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8981875397823742256
,
Apr 20 2017
=== BISECT JOB RESULTS === Perf regression found with culprit Suspected Commit Author : pkotwicz Commit : 98068764b24c38a5f23049fab6d1412271fceee5 Date : Mon Apr 03 16:08:00 2017 Subject: Enable perf bots to test WebAPK variations experiment Bisect Details Configuration: android_nexus5_perf_bisect Benchmark : memory.top_10_mobile_stress Metric : memory:chrome:all_processes:reported_by_os:gpu_memory:proportional_resident_size_avg/background/after_https_m_facebook_com_rihanna Change : 1.89% | 24673621.3333 -> 25140565.3333 Revision Result N chromium@461440 24673621 +- 3739.12 6 good chromium@461443 24674304 +- 0.0 6 good chromium@461444 25130325 +- 59825.9 6 bad <-- chromium@461445 25152171 +- 59825.9 6 bad chromium@461449 25141248 +- 0.0 6 bad chromium@461457 25141248 +- 0.0 6 bad chromium@461474 25140565 +- 3739.12 6 bad Please refer to the following doc on diagnosing memory regressions: https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md To Run This Test src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests memory.top_10_mobile_stress Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8981875397823742256 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5777748456374272 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Speed>Bisection. Thank you!
,
Apr 20 2017
Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8981832877290018944
,
Apr 20 2017
=== BISECT JOB RESULTS === Perf regression found with culprit Suspected Commit Author : pkotwicz Commit : 98068764b24c38a5f23049fab6d1412271fceee5 Date : Mon Apr 03 16:08:00 2017 Subject: Enable perf bots to test WebAPK variations experiment Bisect Details Configuration: android_nexus5_perf_bisect Benchmark : memory.top_10_mobile_stress Metric : memory:chrome:all_processes:reported_by_os:gpu_memory:proportional_resident_size_avg/background/after_https_m_facebook_com_rihanna Change : 2.33% | 24674304.0 -> 25249792.0 Revision Result N chromium@461440 24674304 +- 0.0 6 good chromium@461443 24674304 +- 0.0 6 good chromium@461444 25151488 +- 60684.4 6 bad <-- chromium@461445 25118037 +- 76993.2 6 bad chromium@461449 25261397 +- 589217 6 bad chromium@461457 25141248 +- 0.0 6 bad chromium@461474 25249792 +- 530578 6 bad Please refer to the following doc on diagnosing memory regressions: https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md To Run This Test src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests memory.top_10_mobile_stress Debug Info https://chromeperf.appspot.com/buildbucket_job_status/8981832877290018944 Is this bisect wrong? https://chromeperf.appspot.com/bad_bisect?try_job_id=5243106363965440 | O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq | X | for more information addressing perf regression bugs. For feedback, | / \ | file a bug with component Speed>Bisection. Thank you!
,
May 1 2017
Here's the graph: https://chromeperf.appspot.com/report?sid=83946ae5ccb59f706ae8f959d92a5255ee5ac99683a15b0474ee12e7c9ebbe5d&start_rev=460280&end_rev=468305 Looks like a 500-600kb regression in gpu memory which is surprising
,
May 1 2017
I reproduced the perf regression locally. It has to do with creating the DexClassLoader in DexOptimizer.java I can look into how the memory difference number is computed. Yaron what do you think are the logical next steps?
,
May 1 2017
For the sake of clarity the signature in ChromeWebApkHostSignature has no impact at all
,
May 3 2017
,
May 4 2017
Peter's still doing some digging but we suspect this is a non-issue. It's true there's a single extra allocatoin when the flag is set but it happens exactly once per user - we have a shared pref preventing that allocation from happening again. So yes, we've regressed memory but it's one invocation of a browser so seems like a small issue. We could do some work to mitigate it in the future (e.g. move to a short-lived utility process)
,
May 9 2017
I did some investigation. I have confirmed that this regression is because we call DexOptimizer#optimize() the first time that Chrome is launched. It is possible that the regression that we are seeing is related to this strict mode violation. Note that the strict violation is in Android code not Chrome code. /StrictMode( 9453): A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks. E/StrictMode( 9453): java.lang.Throwable: Explicit termination method 'close' not called E/StrictMode( 9453): at dalvik.system.CloseGuard.open(CloseGuard.java:184) E/StrictMode( 9453): at dalvik.system.DexFile.<init>(DexFile.java:113) E/StrictMode( 9453): at dalvik.system.DexFile.loadDex(DexFile.java:151) E/StrictMode( 9453): at dalvik.system.DexPathList.loadDexFile(DexPathList.java:266) E/StrictMode( 9453): at dalvik.system.DexPathList.makeDexElements(DexPathList.java:221) E/StrictMode( 9453): at dalvik.system.DexPathList.<init>(DexPathList.java:112) E/StrictMode( 9453): at dalvik.system.BaseDexClassLoader.<init>(BaseDexClassLoader.java:48) E/StrictMode( 9453): at dalvik.system.DexClassLoader.<init>(DexClassLoader.java:57) E/StrictMode( 9453): at org.chromium.webapk.lib.client.DexOptimizer.optimize(DexOptimizer.java:71) E/StrictMode( 9453): at org.chromium.chrome.browser.webapps.WebApkVersionManager.updateWebApksIfNeeded(WebApkVersionManager.java:66) E/StrictMode( 9453): at org.chromium.chrome.browser.init.ProcessInitializationHandler$14.doInBackground$10299ca(ProcessInitializationHandler.java:458) E/StrictMode( 9453): at org.chromium.chrome.browser.init.ProcessInitializationHandler$14.doInBackground(ProcessInitializationHandler.java:419) E/StrictMode( 9453): at android.os.AsyncTask$2.call(AsyncTask.java:288) E/StrictMode( 9453): at java.util.concurrent.FutureTask.run(FutureTask.java:237) E/StrictMode( 9453): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112) E/StrictMode( 9453): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587) E/StrictMode( 9453): at java.lang.Thread.run(Thread.java:841) Before DexOptimizer runs memtrack_helper reports for the browser process gl_pss < gl_total (gl_pss=3424256, gl_total=7110656) After DexOptimizer runs memtrack_helper reports for the browser process gl_pss == gl_total (gl_pss=7045120, gl_total=7045120) DexOptimizer running does not affect gl_total I have confirmed that the increase in gl_pss only occurs on Chrome's first run (or after clearing Chrome's data)
,
May 9 2017
primiano@: - What is the meaning of gl_pss and gl_total reported by memtrack_helper.c - Is this regression acceptable if it only occurs on Chrome's first run?
,
May 15 2017
primiano@ Ping!
,
May 15 2017
> - What is the meaning of gl_pss and gl_total reported by memtrack_helper.c gl_pss and gl_total are the equivalent of GL / EGL mtrack in dumpsys meminfo (see https://developer.android.com/studio/profile/investigate-ram.html, https://groups.google.com/a/chromium.org/d/msg/graphics-dev/5VnWUyNW0Fc/nQ0-iLXLAQAJ). > - Is this regression acceptable if it only occurs on Chrome's first run? This really depends what for. did we establish that this ocurs on chrome's first run only? how? did we estabish why dexing an apk causes increases on gpu memory? +benhery, speed TPM, for release-related questions.
,
May 15 2017
This happens the first time you launch chrome after the flag is enabled and then a shared pref is set preventing it from happening again. We didn't determine the latter
,
May 15 2017
I personally don't think there is any concern about regressing +500 K chrome once on first run (or once per update, whatever). I'd just ask that you folks check that this is really once at first run and not always. A constant +500 KB would be quite unfortunate.
,
May 15 2017
Yeah, I'm less concerned about a 1-time regression, but it will probably reset our benchmark baselines. Can we determine if the shared pref is preventing regressions from happening again?
,
May 15 2017
Do we have any memory perf test which restart the browser? Cause those not showing a regression would provide confirmation.
,
May 15 2017
+nednguyen, perezju: can you answer #24?
,
May 15 2017
*24: system_health.memory_desktop & system_health.memory_mobile restart the browser.
,
May 16 2017
It's true that both system_health.memory_desktop & system_health.memory_mobile do restart the browser between stories (most benchmarks nowadays do). But this also includes clearing the browser state and will remove your shared pref. To prevent this (I think) you need to set --profile-type default. So, try running something like, e.g.: $ tools/perf/run_benchmark system_health.memory_mobile --browser android-chromium --story-filter load:social:facebook --pageset-repeat 10 --profile-type default and compare results with/without your patch.
,
May 17 2017
I ran tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --pageset-repeat=1 --also-run-disabled-tests memory.top_10_mobile_stress --story-filter=after_https_m_facebook_com_rihanna --profile-type=default with and without --profile-type=default. When I ran the command with --profile-type=default I observed no regression. Upon clearing Chrome's data from Android Settings, the regression came back
,
May 17 2017
benhenry: I think it is safe to close this bug given my findings in comment #28?
,
May 17 2017
Yeah, sounds like this is just first run of browser regression, so sgtm. I'll let Juan close it in case I'm not thinking correctly.
,
May 18 2017
Also think it's fine to close given the comments in #28. |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by pmeenan@chromium.org
, Apr 5 2017