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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggOzLvAkM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggNHeogoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggJH7pAoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggL-8pwoM,agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICggJGJqAkM


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

android-nexus6
android-nexus7v2
android-nexus9
android-one

Looks like the first bisect job failed because of a bug in bisect (using crrev, now being reverted and fixed).

Bug this looks likely to be a real regression. Two new bisect jobs:
	https://chromeperf.appspot.com/buildbucket_job_status/9017185469345178512
https://chromeperf.appspot.com/buildbucket_job_status/9017185475978473552

Failed because test took over one hour with no output (killed by buildbot.) Launching again.

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

Hi shess@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 : [sqlite] Fix seperate-page-cache page merge issue.
Author  : shess
Commit description:
  
The previous version set a local variable which was picked up by the
SQLite code to set the global.  SQLite stopped using that local
variable, I apparently didn't notice.

BUG= 591962 

Review URL: https://codereview.chromium.org/1769213002

Cr-Commit-Position: refs/heads/master@{#380665}
Commit  : 32fefb99eaec8394ece520cea141c2b7a4fd1ef4
Date    : Fri Mar 11 17:50:24 2016


===== TESTED REVISIONS =====
Revision                Mean Value  Std. Dev.   Num Values  Good?
chromium@380654         38104.833333244.965644  6           good
chromium@380662         38071.8     135.158056  5           good
chromium@380664         37989.2     123.736413  5           good
chromium@380665         39281.4     144.662711  5           bad         <-
chromium@380666         39235.0     111.366512  5           bad
chromium@380670         39261.2     131.044649  5           bad

Bisect job ran on: android_nexus6_perf_bisect
Bug ID: 594436

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --also-run-disabled-tests page_cycler.top_10_mobile
Test Metric: vm_private_dirty_final_browser/vm_private_dirty_final_browser
Relative Change: 3.31%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus6_perf_bisect/builds/2075
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9016546939620107696


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

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

shess, can you please take a look at this regression? It looks like it has recovered on some graphs but not all.

This change fixed an incorrect part of the import of SQLite 3.12 in January.  The current state of this setting matches the previous state, so it's likely that there was a gain in the metric at that time (that CL was at 371085, and as best I can tell there was an improvement in this metric with that CL in range).

If I understand correctly that the metric tracks virtual-memory usage, the pattern of the regression makes some sense, since it affects sharing of cache pages between different database connections.  I would expect the real-world impact to not be large because of clearing of the caches at the ends of transactions, but it's hard to quantify the overall transaction state of the browser at any given time.