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

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=ef69ab0b009bd15361237439ffa921168fca20da37517945c975f61cb88939bf


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

linux-perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/16e18992a40000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/16e18992a40000

Roll src/third_party/catapult 8a075d7c378a..9eaedb7fa00f (1 commits) by catapult-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/b5896b295b3238c960714f1aef991e022c0a45a0
3.266e+07 → 3.944e+07 (+6.784e+06)

Assigning to sheriff sullivan@chromium.org because "Roll src/third_party/catapult 8a075d7c378a..9eaedb7fa00f (1 commits)" is a roll.

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Ned: the only CL in this roll is "Set non blocking I/O read on ts_proxy subprocess stdout to make sure the timeout limit contract is honored in case stdout read is stuck". Is it expected that this would cause a regression in memory? (That could happen if the test ran longer, does that seem to be the case?)

Hmhh, I didn'tt expect that CL to cause any memory regression. How do I rekick the bisect?