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

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


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

android-nexus9

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

=== 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 : Use Share Group rather than Client ID in GPU memory logs
Author  : ericrk
Commit description:
  
Currently, TextureManager and BufferManager in the GPU process log
memory allocations in the form "gpu/gl/client_X/texture|buffer_X",
unfortunately, a single client can have multiple textures or buffers
with the same ID. IDs are only unique within a ShareGroup, not a
client.

To avoid these duplicate entries, this CL moves to logging these
values as "gpu/gl/share_group_X/texture|buffer_X". This ensures that
each entry will have a unique name.

BUG=624701
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel;tryserver.chromium.perf:android_s5_perf_cq;tryserver.chromium.perf:mac_retina_perf_cq

Review-Url: https://codereview.chromium.org/2133743003
Cr-Commit-Position: refs/heads/master@{#405391}
Commit  : 3b37a9689b42738426fdbf9b225d224e704a5af7
Date    : Thu Jul 14 01:37:40 2016


===== TESTED REVISIONS =====
Revision         Mean      Std Dev  N  Good?
chromium@405367  11253255  1873902  8  good
chromium@405382  10364683  1865697  8  good
chromium@405389  10445173  1714531  8  good
chromium@405390  9718798   1644707  5  good
chromium@405391  12663043  203.929  5  bad    <--
chromium@405393  12663066  211.087  8  bad
chromium@405396  12663009  161.22   8  bad
chromium@405424  12662952  0.0      8  bad

Bisect job ran on: android_nexus9_perf_bisect
Bug ID: 631121

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests system_health.memory_mobile
Test Metric: load_tools-memory:chrome:all_processes:reported_by_chrome:gpu:effective_size_avg/load_tools_drive
Relative Change: 6.64%
Score: 99.0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus9_perf_bisect/builds/1917
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9006145041511750688


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

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

Perf sheriff ping: reminder to follow up on possible performance issues

This is just a reporting issue. We had a bug where certain GPU resources were not being tracked / accounted for in memory-infra. The CL in question fixed our tracking so we countthese additional GPU resources. This would lead to higher reporting numbers, but only because we are reporting things we missed in the past.