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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZy2wELEhNTdG9wcGFnZUFsZXJ0UGFyZW50IqwBQ2hyb21pdW1QZXJmL2FuZHJvaWQtbmV4dXM3djIvbWVtb3J5LnRvcF8xMF9tb2JpbGVfc3RyZXNzL21lbW9yeTpjaHJvbWU6YWxsX3Byb2Nlc3NlczpyZXBvcnRlZF9ieV9jaHJvbWU6Y2M6ZWZmZWN0aXZlX3NpemVfYXZnL2JhY2tncm91bmQvYWZ0ZXJfaHR0cHNfbV9mYWNlYm9va19jb21fcmloYW5uYQwLEg1TdG9wcGFnZUFsZXJ0GLTdGww,agxzfmNocm9tZXBlcmZy3QELEhNTdG9wcGFnZUFsZXJ0UGFyZW50Iq4BQ2hyb21pdW1QZXJmL2FuZHJvaWQtd2Vidmlldy1uZXh1czVYL21lbW9yeS50b3BfMTBfbW9iaWxlL21lbW9yeTp3ZWJ2aWV3OmFsbF9wcm9jZXNzZXM6cmVwb3J0ZWRfYnlfY2hyb21lOmdwdTplZmZlY3RpdmVfc2l6ZV9hdmcvYmFja2dyb3VuZC9hZnRlcl9odHRwc19tX2ZhY2Vib29rX2NvbV9yaWhhbm5hDAsSDVN0b3BwYWdlQWxlcnQYoq8bDA,agxzfmNocm9tZXBlcmZy6wELEhNTdG9wcGFnZUFsZXJ0UGFyZW50IrwBQ2hyb21pdW1QZXJmL2FuZHJvaWQtd2Vidmlldy1uZXh1czVYL21lbW9yeS50b3BfMTBfbW9iaWxlL21lbW9yeTp3ZWJ2aWV3OmFsbF9wcm9jZXNzZXM6cmVwb3J0ZWRfYnlfY2hyb21lOmdwdTplZmZlY3RpdmVfc2l6ZV9hdmcvYmFja2dyb3VuZC9hZnRlcl9odHRwX3NlYXJjaF95YWhvb19jb21fc2VhcmNoX195bHRfcF9nb29nbGUMCxINU3RvcHBhZ2VBbGVydBiirxsM,agxzfmNocm9tZXBlcmZy3AELEhNTdG9wcGFnZUFsZXJ0UGFyZW50Iq0BQ2hyb21pdW1QZXJmL2FuZHJvaWQtd2Vidmlldy1uZXh1czVYL21lbW9yeS50b3BfMTBfbW9iaWxlL21lbW9yeTp3ZWJ2aWV3OmFsbF9wcm9jZXNzZXM6cmVwb3J0ZWRfYnlfY2hyb21lOmNjOmVmZmVjdGl2ZV9zaXplX2F2Zy9iYWNrZ3JvdW5kL2FmdGVyX2h0dHBzX21fZmFjZWJvb2tfY29tX3JpaGFubmEMCxINU3RvcHBhZ2VBbGVydBiirxsM,agxzfmNocm9tZXBlcmZy6gELEhNTdG9wcGFnZUFsZXJ0UGFyZW50IrsBQ2hyb21pdW1QZXJmL2FuZHJvaWQtd2Vidmlldy1uZXh1czVYL21lbW9yeS50b3BfMTBfbW9iaWxlL21lbW9yeTp3ZWJ2aWV3OmFsbF9wcm9jZXNzZXM6cmVwb3J0ZWRfYnlfY2hyb21lOmNjOmVmZmVjdGl2ZV9zaXplX2F2Zy9iYWNrZ3JvdW5kL2FmdGVyX2h0dHBfc2VhcmNoX3lhaG9vX2NvbV9zZWFyY2hfX3lsdF9wX2dvb2dsZQwLEg1TdG9wcGFnZUFsZXJ0GKKvGww


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

android-nexus7v2
android-webview-nexus5X

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

+ssid, +primiano

It looks like *some* metrics (cc and gpu) have stopped reporting for *some* background pages on the android-webview-nexus5X bot.

See e.g.:
https://chromeperf.appspot.com/report?sid=ba287e28139326a71a2ab3fb1ecd25eac6a00945662fe324aaaca92fb4e01a79&rev=448418

Maybe this is OK, and just means that cc and gpu memory is not being used for those cases since we're in background? I've checked and many on the regular (non-webview) N5 bot and cc/gpu have not been reported for a long while in most background pages.

This is another of those instances where it's unclear whether the metric "is missing but should be there" or "is missing because it's zero". Perhaps there should be a better way to distinguish between the two.

+ericrk : it seems that some pages (but not all) stopped reporting gpu and cc memory in background.
I suspect this is just WAI (probably a side effect of crrev.com/2669323002) as we end up dropping all resources from the chrome side and the CC / GPU MDP have essentially nothing to declare.
One thing that perezju was pointing out, is that would be nice if we could distinguish between "the cc MDP has been invoked and its result is just 0" vs "there could be some bug and we are not invoking the cc MDP".

So I wonder if we could tweak the cc MDP and emit empty entires to make this explicitly.
perezju@ can I ask you do to a quick test: if you manually inject an empty "cc/tile_memory" entry with no size column in the trace, does it show up as a "0" in the metric?
If so the resolution here would be a one line in the chrome side.

=== BISECT JOB RESULTS ===
NO Test failure found

Bisect Details
  Configuration: android_webview_arm64_aosp_perf_bisect
  Benchmark    : memory.top_10_mobile
  Metric       : memory:webview:all_processes:reported_by_chrome:gpu:effective_size_avg/background/after_https_m_facebook_com_rihanna

Revision             Exit Code      N
chromium@448418      0 +- N/A       20      good
chromium@448494      0 +- N/A       20      bad

Please refer to the following doc on diagnosing memory regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/memory_benchmarks.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=android-webview --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests memory.top_10_mobile

Debug Info
  https://chromeperf.appspot.com/buildbucket_job_status/8983983774531740032

Is this bisect wrong?
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5787378465112064


| 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 Speed>Bisection.  Thank you!

I had a look and it looks like no, a size column with a value of 0 needs to be present for it to be picked up by the metric.

Namely, if |event| is the trace event with memory dumps, we need at least:

event['args']['dumps']['allocators']['cc/tile_memory'] = {
  'attrs': {
    'size': {
      'type': 'scalar',
      'units': 'bytes',
      'value': '0'
    }
  }
}

for the value to be picked up.

Probably WAI - I'll add some logic to the MDPs to dump 0 if there's nothing to dump, which should make this clearer.

Just to clarify, will this also fix the issue for gpu:effective_size? As mentioned on #4, both cc and gpu went missing for this particular case.

 Issue 705469  has been merged into this issue.

Sure, I can look at GPU as well.

erickrk: are you still working on this?

+hjd FYI