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

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


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

android-nexus5X
chromium-rel-mac12

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/11c50391840000

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

Bugfix rerun selector after deleting canceled tasks by alexclarke@chromium.org
chromium @ cdbc3669564ce09f57d7139e378f249b1a5ef30a

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

This is a super noisy benchmark, re-running.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1683dd91840000

😿 Pinpoint job stopped with an error.
https://pinpoint-dot-chromeperf.appspot.com/job/1683dd91840000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/107d55fe440000

Looks like the desktop regression was noise; removed it from the bug, but re-kicking the bisect on mobile.

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

Bugfix rerun selector after deleting canceled tasks by alexclarke@chromium.org
https://chromium.googlesource.com/chromium/src/+/cdbc3669564ce09f57d7139e378f249b1a5ef30a

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

I'm tempted to Wont Fix this.  The patch fixes a bug where tasks where sometimes being run out of order which breaks a fundamental guarantee of the scheduler.  

Perhaps we just got unlucky here, for some reason this test is sensitive to the order things are run in, and that results in something being retained longer than normal.

I don't think we want to re-introduce a bug which resulted in unexpected task reordering just because of this single regression.