Issue metadata
Sign in to add a comment
|
102.9% regression in memory.blink_memory_mobile/memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg on android-nexus5X at 402675:402715 |
||||||||||||||||||||
Issue descriptionPerformance dashboard identified a 102.9% regression in memory.blink_memory_mobile/memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg on android-nexus5X at revision range 402675:402715. Graph: https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg4pSTsgoM
,
Jun 30 2016
=== Auto-CCing suspected CL author vmiura@chromium.org === Hi vmiura@chromium.org, the bisect results pointed to your CL below as possibly causing a regression. Please have a look at this info and see whether your CL be related. ===== BISECT JOB RESULTS ===== Status: completed ===== SUSPECTED CL(s) ===== Subject : Re-enable GPU Rasterization for content with any author defined viewport. Author : vmiura Commit description: BUG= 591179 Review-Url: https://codereview.chromium.org/2097413003 Cr-Commit-Position: refs/heads/master@{#402702} Commit : a017b667a53b3ee5f8bc630be98c37ebf53a2339 Date : Wed Jun 29 03:37:05 2016 ===== TESTED REVISIONS ===== Revision Mean Std Dev N Good? chromium@402674 4418066 114268 5 good chromium@402695 4418805 96314.4 5 good chromium@402700 4410923 112899 5 good chromium@402701 4466541 139393 5 good chromium@402702 9043552 61250.2 5 bad <-- chromium@402703 9000909 58879.9 5 bad chromium@402705 8991434 65902.7 5 bad chromium@402715 9034866 32702.7 5 bad Bisect job ran on: android_nexus5X_perf_bisect Bug ID: 624630 Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests memory.blink_memory_mobile Test Metric: memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg/memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg Relative Change: 104.50% Score: 99.9 Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5X_perf_bisect/builds/268 Job details: https://chromeperf.appspot.com/buildbucket_job_status/9008471752272074416 Not what you expected? We'll investigate and get back to you! https://chromeperf.appspot.com/bad_bisect?try_job_id=5729269683060736 | 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 Tests>AutoBisect. Thank you!
,
Jun 30 2016
Thanks for the alert. What does this test measure?
,
Jun 30 2016
This measures amount of memory reported by skia in the renderer. You can eyeball the traces for the facebook page before and after here (Traces collected by the bot): before: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_1-2016-06-28_20-33-45-42862.html after: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_1-2016-06-28_21-59-42-85943.html If you look at the trace column there are a bunch (17 MB) of gpu resources reported under skia (they seem textures). The interesting thing is that they seem "purgeable" (it has a purgeable_size column). Not sure what that means, I am not a skia expert. See attached screenshot.
,
Jun 30 2016
Purgeable in Skia means that we *could* free the memory (it's not being actively used) - but that doesn't mean we should - if we use the memory quickly each frame, it will still be purgeable for the majority of the frame. That said, when moving from something like SW to GPU raster, I don't think that a super specific metric like this is too interesting. This just means that Skia started using more memory - however, it doesn't take into account improvements in other areas (I would expect that tile memory was reduced). If you look at some other areas, it looks like we had a reduction in both cc::efective_Size_avg and discardable:locked_size_avg (discardable is really noisy, but all spikes have disappeared since the patch landed). We see regressions in gpu::effective_size_avg and skia:effective_size_avg. It looks like there may still be a slight regression - however it's not really at the scale indicated here.
,
Jun 30 2016
Ah, looked at the facebook traces included here (these show a worse regression than the overall telemetry trend) - in these we are definitely using more memory. Looking at the Skia objects, which are perfectly sized (512k, 1024k, 2048K and 4096k) - my guess is that these are temprorary buffers used by Skia in rendering. It may be that we need to more aggressively clean up these resources? It also looks like we use a bit more GPU memory for images in CC - if we purged unused images after X frames, we could likely drive this number down. I had been avoiding doing this, as this will hurt performance, and if we have the memory, it seems like we should use it?
,
Jul 1 2016
FYI, you don't need to care about "purgeable_size" but you should care about "effective_size" because it's designed to represent actual amount of memory used by a component (in this case, skia). I think using more memory is fine if we have enough and there is certain improvement on other metrics but I'd like to see the clarification.
,
Jul 7 2016
vmiura@: any update?
,
Jul 7 2016
I believe vmiura@ is OOO this week and next. He can give probably give more info, but from previous conversations I remember that this change results in an improvement to (non-webview) system health metrics. Primiano, do you recall the numbers here? Additionally, as I pointed out in #5, I think that looking at this as a large regression is misleading. Looking at Skia in isolation doesn't tell us the full story for a large change like this, as the change effects a number of categories. If we look at overall renderer effective size (https://chromeperf.appspot.com/report?sid=388adafd8a3310bc7e668538a744cf537c33289615ae5698c45e6e782f28036e), we see a regression from about 150MB to 155MB - this is only about a 3.3% regression. Even on Facebook, which shows the bad Skia regression posted above, overall renderer effective size only changes from ~217MB to ~232MB, a 6.5% regression. So it seems like we should likely be treating this as a small (~5%) regression. If we did want to improve things, we could cause Skia or Image Decode Controller to more aggressively evict not-recently-used resources. This would lower memory usage, but would also hurt performance the next time raster was required.
,
Jul 8 2016
Thanks ericrk@ for the reply. I understand your point but I'm uneasy to think this kind of regressions as small. 3-7% regression of total memory usage is huge. I don't think it's acceptable without having *strong* improvement on other numbers. I'd like to see the actual improvement.
,
Jul 19 2016
Issue 629498 has been merged into this issue.
,
Jul 19 2016
@ericrk @bashi: Note that the regression is not limited to memory metrics and impacts input and frame times on NYTimes, mlb.com, and youtube on nexus devices - 300% regression in first_gesture_scroll_update_latency for NYTimes - 75% regress in mean_input_event_latency for NYtimes - 40% regress in mean_input_event_latency for mlb.com I am not sure why that is. Naively I would have thought GPU rasterization would have positive impact on these metrics as it reduces load on CPU.
,
Jul 20 2016
,
Jul 22 2016
majidvp@, thanks for the additional info! Which graphs are showing the first_gesture_scroll_update_latency issues and mean_input_event_latency issues you mention? I'm looking at smoothness.key_mobile_sites_smooth and am seeing some changes, but not exactly what you describe - want to make sure we're looking at the same thing - have these changes/graphs been associated with a bug?
,
Jul 22 2016
+majidvp@ for the above question. Thanks!.
,
Jul 22 2016
@ericrk@: See graph in the two bugs marked as duplicate (Issue 629498, Issue 629502 ) Here are the direct links: https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqpGNuQoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqt_DsgoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg6tTCuAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqrbzogoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqrvzvAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqorXtwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqpufuwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqpTKrAsM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg6sjBrAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqsWstAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqvL8qAoM https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqr-roAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgqu-eqgoM
,
Aug 5 2016
Issue 629505 has been merged into this issue.
,
Aug 17 2016
,
Sep 20 2016
Have a fix in progress for this.
,
Sep 20 2016
crrev.com/2286873003 is a prerequesite for the fix - submitted: Provide TaskRunner to ContextCacheController Both ContextCacheController and the CommandBuffer/GpuControl need access to a TaskRunner. CommandBuffer/GpuControl currently creates this TaskRunner internally in most cases. This change moves TaskRunner creation to the ContextProvider, allowing the same TaskRunner to be passed to both objects. CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Committed: https://crrev.com/d989e6a0815a6f77d3a6fbab24afe9ff6abbf25e Cr-Commit-Position: refs/heads/master@{#419553}
,
Sep 22 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/051ae83bf29b52cefd82235ebfb90f203912afbb commit 051ae83bf29b52cefd82235ebfb90f203912afbb Author: ericrk <ericrk@chromium.org> Date: Thu Sep 22 23:20:23 2016 Idle cleanup for worker context Currently, Skia flushes unused items out of its caches after ~1 second of non-use (50 flushes). This works fine while Skia is in-use, but when a worker context goes idle we stop calling into Skia altogether. This means that Skia will never flush out unused cache items from the last piece of work it did. This can lead to some rather large temporaries being kept around (~20mb). This change adds an idle cleanup process which flushes Skia's caches and cleans up worker context resources after a worker context is idle for 1 second. BUG= 624630 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2353033003 Cr-Commit-Position: refs/heads/master@{#420496} [modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/BUILD.gn [modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/output/context_cache_controller.cc [modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/output/context_cache_controller.h [modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/output/context_cache_controller_unittest.cc [add] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/output/context_provider.cc [modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/output/context_provider.h [modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/content/common/gpu/client/context_provider_command_buffer.cc
,
Sep 23 2016
With #21 landed this has changed from a large regression to a medium improvement. Seeing ~1.5MB savings on this metric across all bots (compared to pre-regression numbers).
,
Sep 23 2016
This is great! I wish all regressions ended in such significant savings :)
,
Sep 23 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c commit a5ce62a749a47a57f8b3b2734eea4cec31e39d9c Author: ericrk <ericrk@chromium.org> Date: Fri Sep 23 21:51:37 2016 Revert of Idle cleanup for worker context (patchset #5 id:200001 of https://codereview.chromium.org/2353033003/ ) Reason for revert: This appears to be breaking some number of unittests - need to investigate further. Original issue's description: > Idle cleanup for worker context > > Currently, Skia flushes unused items out of its caches after ~1 second > of non-use (50 flushes). This works fine while Skia is in-use, but when > a worker context goes idle we stop calling into Skia altogether. This > means that Skia will never flush out unused cache items from the last > piece of work it did. This can lead to some rather large temporaries > being kept around (~20mb). > > This change adds an idle cleanup process which flushes Skia's caches > and cleans up worker context resources after a worker context is idle > for 1 second. > > BUG= 624630 > CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel > > Committed: https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb > Cr-Commit-Position: refs/heads/master@{#420496} TBR=danakj@chromium.org,jbauman@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= 624630 Review-Url: https://codereview.chromium.org/2366033002 Cr-Commit-Position: refs/heads/master@{#420741} [modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/cc/BUILD.gn [modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/cc/output/context_cache_controller.cc [modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/cc/output/context_cache_controller.h [modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/cc/output/context_cache_controller_unittest.cc [delete] https://crrev.com/a11540e8d7eb302bcef2f7c9010da5f693071035/cc/output/context_provider.cc [modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/cc/output/context_provider.h [modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/content/common/gpu/client/context_provider_command_buffer.cc
,
Sep 24 2016
Your change meets the bar and is auto-approved for M54 (branch: 2840)
,
Sep 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6714c23b526197220d8b9abdbd38b6d9c206d912 commit 6714c23b526197220d8b9abdbd38b6d9c206d912 Author: ericrk <ericrk@chromium.org> Date: Tue Sep 27 03:35:01 2016 Idle cleanup for worker context Currently, Skia flushes unused items out of its caches after ~1 second of non-use (50 flushes). This works fine while Skia is in-use, but when a worker context goes idle we stop calling into Skia altogether. This means that Skia will never flush out unused cache items from the last piece of work it did. This can lead to some rather large temporaries being kept around (~20mb). This change adds an idle cleanup process which flushes Skia's caches and cleans up worker context resources after a worker context is idle for 1 second. BUG= 624630 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel;master.tryserver.blink:linux_precise_blink_dbg Committed: https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb Review-Url: https://codereview.chromium.org/2353033003 Cr-Original-Commit-Position: refs/heads/master@{#420496} Cr-Commit-Position: refs/heads/master@{#421092} [modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/BUILD.gn [modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/output/context_cache_controller.cc [modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/output/context_cache_controller.h [modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/output/context_cache_controller_unittest.cc [add] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/output/context_provider.cc [modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/output/context_provider.h [modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/content/common/gpu/client/context_provider_command_buffer.cc
,
Sep 28 2016
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c7bc434acf21c0330022455bb9f584c764991567 commit c7bc434acf21c0330022455bb9f584c764991567 Author: Eric Karl <ericrk@chromium.org> Date: Thu Sep 29 22:11:46 2016 Provide TaskRunner to ContextCacheController Both ContextCacheController and the CommandBuffer/GpuControl need access to a TaskRunner. CommandBuffer/GpuControl currently creates this TaskRunner internally in most cases. This change moves TaskRunner creation to the ContextProvider, allowing the same TaskRunner to be passed to both objects. CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2286873003 Cr-Commit-Position: refs/heads/master@{#419553} (cherry picked from commit d989e6a0815a6f77d3a6fbab24afe9ff6abbf25e) BUG= 624630 Review URL: https://codereview.chromium.org/2376123005 . Cr-Commit-Position: refs/branch-heads/2840@{#588} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/android_webview/browser/aw_render_thread_context_provider.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller_unittest.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/raster/raster_buffer_provider_perftest.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_context_provider.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_in_process_context_provider.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_in_process_context_provider.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/gl_helper_benchmark.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/gl_helper_unittest.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/yuv_readback_unittest.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/content/common/gpu/client/context_provider_command_buffer.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/client/gl_in_process_context.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/client/gl_in_process_context.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/service/in_process_command_buffer.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/service/in_process_command_buffer.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/ipc/client/command_buffer_proxy_impl.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/ipc/client/gpu_in_process_context_tests.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/demo/bitmap_uploader.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/context_provider.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/gles2_context.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/gles2_context.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/surfaces/surfaces_context_provider.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/surfaces/surfaces_context_provider.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/ui/compositor/test/in_process_context_provider.cc
,
Sep 29 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/afec5ef67b207063bfbff5a5768b95b327393026 commit afec5ef67b207063bfbff5a5768b95b327393026 Author: Eric Karl <ericrk@chromium.org> Date: Thu Sep 29 22:17:16 2016 Idle cleanup for worker context Currently, Skia flushes unused items out of its caches after ~1 second of non-use (50 flushes). This works fine while Skia is in-use, but when a worker context goes idle we stop calling into Skia altogether. This means that Skia will never flush out unused cache items from the last piece of work it did. This can lead to some rather large temporaries being kept around (~20mb). This change adds an idle cleanup process which flushes Skia's caches and cleans up worker context resources after a worker context is idle for 1 second. BUG= 624630 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel;master.tryserver.blink:linux_precise_blink_dbg Committed: https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb Review-Url: https://codereview.chromium.org/2353033003 Cr-Original-Commit-Position: refs/heads/master@{#420496} Cr-Commit-Position: refs/heads/master@{#421092} (cherry picked from commit 6714c23b526197220d8b9abdbd38b6d9c206d912) Review URL: https://codereview.chromium.org/2382063002 . Cr-Commit-Position: refs/branch-heads/2840@{#590} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/BUILD.gn [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller.cc [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller.h [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller_unittest.cc [add] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_provider.cc [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_provider.h [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/content/common/gpu/client/context_provider_command_buffer.cc
,
Sep 29 2016
My CL above addresses the memory concerns in this bug. I've forked the performance concerns to crbug.com/651605 and crbug.com/651607 , which are still open. Closing this out.
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c7bc434acf21c0330022455bb9f584c764991567 commit c7bc434acf21c0330022455bb9f584c764991567 Author: Eric Karl <ericrk@chromium.org> Date: Thu Sep 29 22:11:46 2016 Provide TaskRunner to ContextCacheController Both ContextCacheController and the CommandBuffer/GpuControl need access to a TaskRunner. CommandBuffer/GpuControl currently creates this TaskRunner internally in most cases. This change moves TaskRunner creation to the ContextProvider, allowing the same TaskRunner to be passed to both objects. CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2286873003 Cr-Commit-Position: refs/heads/master@{#419553} (cherry picked from commit d989e6a0815a6f77d3a6fbab24afe9ff6abbf25e) BUG= 624630 Review URL: https://codereview.chromium.org/2376123005 . Cr-Commit-Position: refs/branch-heads/2840@{#588} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/android_webview/browser/aw_render_thread_context_provider.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller_unittest.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/raster/raster_buffer_provider_perftest.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_context_provider.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_in_process_context_provider.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_in_process_context_provider.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/gl_helper_benchmark.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/gl_helper_unittest.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/yuv_readback_unittest.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/content/common/gpu/client/context_provider_command_buffer.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/client/gl_in_process_context.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/client/gl_in_process_context.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/service/in_process_command_buffer.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/service/in_process_command_buffer.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/ipc/client/command_buffer_proxy_impl.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/ipc/client/gpu_in_process_context_tests.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/demo/bitmap_uploader.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/context_provider.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/gles2_context.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/gles2_context.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/surfaces/surfaces_context_provider.cc [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/surfaces/surfaces_context_provider.h [modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/ui/compositor/test/in_process_context_provider.cc
,
Oct 27 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/afec5ef67b207063bfbff5a5768b95b327393026 commit afec5ef67b207063bfbff5a5768b95b327393026 Author: Eric Karl <ericrk@chromium.org> Date: Thu Sep 29 22:17:16 2016 Idle cleanup for worker context Currently, Skia flushes unused items out of its caches after ~1 second of non-use (50 flushes). This works fine while Skia is in-use, but when a worker context goes idle we stop calling into Skia altogether. This means that Skia will never flush out unused cache items from the last piece of work it did. This can lead to some rather large temporaries being kept around (~20mb). This change adds an idle cleanup process which flushes Skia's caches and cleans up worker context resources after a worker context is idle for 1 second. BUG= 624630 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel;master.tryserver.blink:linux_precise_blink_dbg Committed: https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb Review-Url: https://codereview.chromium.org/2353033003 Cr-Original-Commit-Position: refs/heads/master@{#420496} Cr-Commit-Position: refs/heads/master@{#421092} (cherry picked from commit 6714c23b526197220d8b9abdbd38b6d9c206d912) Review URL: https://codereview.chromium.org/2382063002 . Cr-Commit-Position: refs/branch-heads/2840@{#590} Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607} [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/BUILD.gn [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller.cc [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller.h [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller_unittest.cc [add] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_provider.cc [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_provider.h [modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/content/common/gpu/client/context_provider_command_buffer.cc |
|||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||
Comment 1 by bashi@chromium.org
, Jun 30 2016