web_cache:effective_size_avg increased from 600K to 25M

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

Ok I eyeballed the traces,
before: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_3-2016-09-15_14-55-18-94580.html
after: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_3-2016-09-15_20-21-32-83208.html

there is no real regression (hence the lack of an alert here is WAI).
In fact all the root allocators and the private_dirty/pss probes are unchanged.

The problem here is that something in the range screwed up the memory reported by web cache.
web_cache is now reporting a crazy amount of memory (24 M, previously was 600k) but there aren't 24 M in any heap. As a consequence this is dropping on the floor the value of partition_alloc. 
Essentially here webcache is saying "I declare 24 M of usage and I declare I'm taking them from partition_Alloc". and partition_Alloc says "well, my heap was just 4.7M. I'll make my effective_size 0 because webcache is asking me to -24, whatever"

So the real problem here is figuring out what screwed up the reporting of webcache

ssid, I strongly suspect this is 
https://codereview.chromium.org/2337733002

:)

===== BISECT JOB RESULTS =====
Status: failed


===== TESTED REVISIONS =====
Revision         Mean      Std Dev  N  Good?
chromium@418923  617143    2568.79  5  good
chromium@418944  615420    2030.81  5  good
chromium@418955  614846    2402.89  5  good
chromium@418958  24950246  130993   5  bad
chromium@418960  24987087  109221   5  bad
chromium@418965  24972012  116991   5  bad
chromium@419007  24993622  121414   5  bad

Bisect job ran on: android_one_perf_bisect
Bug ID: 654715

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests system_health.memory_mobile
Test Metric: memory:chrome:renderer_processes:reported_by_chrome:web_cache:effective_size_avg/browse_news/browse_news_flipboard
Relative Change: 3949.89%
Score: 0

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_one_perf_bisect/builds/1709
Job details: https://chromeperf.appspot.com/buildbucket_job_status/8999100639533180256


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

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/df8812aed3208ee6bc40161df33e2b4b9be5521a

commit df8812aed3208ee6bc40161df33e2b4b9be5521a
Author: ssid <ssid@chromium.org>
Date: Thu Oct 13 05:02:37 2016

Revert changes made to ImageResource memory accounting at crrev.com/2337733002

The actual fix for image resources being misaccounted is done in
crrev.com/2393113002. The m_image should not be counted for each resource
since it is shared.

BUG= 654715 

Review-Url: https://codereview.chromium.org/2417673003
Cr-Commit-Position: refs/heads/master@{#424960}

[modify] https://crrev.com/df8812aed3208ee6bc40161df33e2b4b9be5521a/third_party/WebKit/Source/core/fetch/ImageResource.cpp
[modify] https://crrev.com/df8812aed3208ee6bc40161df33e2b4b9be5521a/third_party/WebKit/Source/core/fetch/ImageResource.h
[modify] https://crrev.com/df8812aed3208ee6bc40161df33e2b4b9be5521a/third_party/WebKit/Source/platform/SharedBuffer.cpp

Sorry for the miscounting. Graphs are back down. The second graph has a different regression. Should be another bug.