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

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


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

android-nexus5X

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

=== PERF REGRESSION ===


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

Hi ericrk@chromium.org, the bisect results pointed to your CL, please take a look at the
results.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Add UMAs for GL context memory usage
Author  : ericrk
Commit description:
  
Adds 6 new UMA metrics which log GL context memory. Memory is logged separately for WebGL and GLES contexts. Additionally, logging occurs at three points - periodically (every 1s), at shutdown, and when the GPU process gets a CRITICAL memory pressure signal. The new histograms are:

GPU.ContextMemory.WebGL.Periodic
GPU.ContextMemory.WebGL.Shutdown
GPU.ContextMemory.WebGL.Pressure
GPU.ContextMemory.GLES.Periodic
GPU.ContextMemory.GLES.Shutdown
GPU.ContextMemory.GLES.Pressure

BUG= 667013 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2577843002
Cr-Commit-Position: refs/heads/master@{#440882}
Commit  : b10572ad91a13dfe5b6faef18990d8464714e666
Date    : Wed Dec 28 19:56:52 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev    N   Good?
chromium@440867  3.16864  0.0925305  9   good
chromium@440876  3.16464  0.160785   14  good
chromium@440880  3.15017  0.0764648  6   good
chromium@440881  3.14738  0.109005   6   good
chromium@440882  3.22486  0.0516894  6   bad    <--
chromium@440884  3.21952  0.0825207  9   bad

Bisect job ran on: android_nexus5X_perf_bisect
Bug ID: 677476

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=set.timeout.html..Long.Idle. thread_times.key_idle_power_cases
Test Metric: tasks_per_second_total_all/set-timeout.html (Long Idle)
Relative Change: 1.61%

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


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

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

Surprised that something which briefly logs every 1s would have this kind of impact.... Will double check to make sure the timer is working as expected.

Perf sheriff checking in, any update on this?

Ok, misread the test - given that I'm adding a task that runs once a second, it's somewhat understandable that the "tasks_per_second_total_all" metric would regress some amount.

I doubt that running one short-lived task per second is worth worrying about (records an UMA and returns). This could probably be run less frequently (it would just slightly lower the quality of the data).

perf sheriff question: would you prefer that this monitoring task run every 5 or 30 seconds for example? Not sure how concerned we should really be about this?

Per comments in #6, closing as Won'tFix, please re-open if we feel that this amount of task execution is too much.