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

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


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

linux-perf

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1496970aa40000

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

Roll AFDO from 69.0.3481.0_rc-r1 to 69.0.3482.0_rc-r1 by afdo-chromium-autoroll@skia-buildbots.google.com.iam.gserviceaccount.com
https://chromium.googlesource.com/chromium/src/+/ac6f267da8542f300d071cbaea765c94407d78f5
115.3 → 116.5 (+1.148)

Assigning to sheriff gbiv@chromium.org because "Roll AFDO from 69.0.3481.0_rc-r1 to 69.0.3482.0_rc-r1" is a roll.

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

Ack. The AFDO pipeline has made Chrome's binary size on Linux fluctuate quite a bit recently. Looks like it's starting to calm down; I'll watch the graph to see if it recovers.

Having trouble telling if this is recovered, given the noise + that this is a 3% regression.

The troughs and (what I assume is) the red noise margin now appear to be at the same level as before this regression, so I'm assuming we're good here. Please feel free to reopen if you disagree.