All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=898899

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=673bf3e151fe532840f067d273de38b1d352f318926527e3a4d05a89982ced1d


Bot(s) for this bug's original alert(s):

mac-10_12_laptop_low_end-perf
mac-10_13_laptop_high_end-perf

system_health.memory_desktop - Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/101eb9cee40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/101eb9cee40000

cc: Avoid acquiring the context lock if unnecessary. by khushalsagar@chromium.org
https://chromium.googlesource.com/chromium/src/+/5d4e09620ff79ac668c72ad3677f993b75e617ce
memory:chrome:all_processes:reported_by_os:system_memory:private_footprint_size: 1.477e+08 → 1.516e+08 (+3.911e+06)

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Benchmark documentation link:
  https://bit.ly/system-health-benchmarks

This change restores us back to the value we were at before https://chromium.googlesource.com/chromium/src/+/cd8fbb77cfa164eef66378204a588443af9bb875. Its meant to fix a bug that was introduced in the previous change.

The change affected the timing of when a cleanup task runs in the renderer for skia/worker context resources for the worse in a lot of cases. Looks like it might have inadvertently triggered in some cases where it wasn't happening earlier?