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

Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg-ZeFugoM


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

chromium-rel-win7-x64-dual

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

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

Hi kbr@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 : Revert of Prevent redundant DoWorks due to canceled delayed tasks  (patchset #6 id:100001 of https://codereview.chromium.org/2320403003/ )
Author  : kbr
Commit description:
  
Reason for revert:
Suspect that this CL caused breakage in Gmail and Hangouts per  http://crbug.com/647484  .

Original issue's description:
> Prevent redundant DoWorks due to canceled delayed tasks
>
> To achieve this we make a few changes:
>
> 1. We only register the next wakeup with the TimeDomain, rather than all
> of them.
> 2. MoveReadyDelayedTasksToDelayedWorkQueue now registers the next
> wakeup (if any).  Since it removes all canceled delayed tasks from the
> front of the priority queue this has the effect of not scheduling
> wakeups for cancelled tasks.
> 3. Tweaking the TaskQueueManager level delayed DoWork de-duplication
> logic to only post a delayed DoWork if the task is meant to run before
> any previously registered delayed DoWorks.
>
> BUG= 638542 ,  605718 
>
> Committed: https://crrev.com/929cbb9f92b5570867c3842c80778243db81a013
> Cr-Commit-Position: refs/heads/master@{#418556}

TBR=skyostil@chromium.org,alexclarke@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 638542 ,  605718 

Review-Url: https://codereview.chromium.org/2353473003
Cr-Commit-Position: refs/heads/master@{#419542}
Commit  : 04e1e5cab53931ea11d58a578a237d6a5762a054
Date    : Mon Sep 19 21:02:36 2016


===== TESTED REVISIONS =====
Revision         Mean   Std Dev  N  Good?
chromium@419514  194.4  1.14018  5  good
chromium@419529  192.8  1.48324  5  good
chromium@419536  193.2  1.48324  5  good
chromium@419540  192.2  1.30384  5  good
chromium@419541  193.2  2.94958  5  good
chromium@419542  200.6  1.51658  5  bad    <--
chromium@419543  201.6  1.14018  5  bad

Bisect job ran on: win_x64_perf_bisect
Bug ID: 648699

Test Command: src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --also-run-disabled-tests sunspider
Test Metric: Total/Total
Relative Change: 3.70%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/win_x64_perf_bisect/builds/1475
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9000974648325439904


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

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

Looks like this alert isn't a regression, just a temporary revert of a previous improvement. My apologies for missing that on the graph.

Correct, that revert was associated with P0  bug 647484 .

The patch relanded and the regression has gone.