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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICgpeC3twoM


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

android-nexus5X

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/9000578839628570544

=== Auto-CCing suspected CL author ericrk@chromium.org ===

Hi ericrk@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 : Idle cleanup for worker context
Author  : ericrk
Commit description:
  
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}
Commit  : 051ae83bf29b52cefd82235ebfb90f203912afbb
Date    : Thu Sep 22 23:22:11 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N  Good?
chromium@420458  4.20339  0.0216029  5  good
chromium@420488  4.2129   0.0449141  5  good
chromium@420492  4.20653  0.0885513  5  good
chromium@420494  4.16285  0.0448881  5  good
chromium@420495  4.18438  0.040733   5  good
chromium@420496  4.98128  0.0548793  5  bad    <--
chromium@420503  5.00305  0.0533208  5  bad
chromium@420517  5.05214  0.0638831  5  bad

Bisect job ran on: android_nexus5X_perf_bisect
Bug ID: 650024

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests thread_times.key_idle_power_cases
Test Metric: tasks_per_second_total_all/animated-gif.html
Relative Change: 20.19%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5X_perf_bisect/builds/695
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9000578839628570544


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5865929844457472

| 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!

This is somewhat expected. As long as rasterization doesn't go completely idle (like in the case of an animated gif), we will spawn 1 task per second to monitor our idle state. Once we become truly idle, this task will terminate after freeing resources.

I'm not too concerned by a task count increase of 1 per second, as we get a benefit from it (performing idle cleanup).