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

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


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

android-nexus5

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

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

[TaskScheduler] Introduce HeartbeatLatencyMicroseconds metric. by gab@chromium.org
https://chromium.googlesource.com/chromium/src/+/3fb9e4fe6f5e51574d0647ee0adc0462da885c61

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

@vmiura : can you help me understand this metric?

android-nexus5/thread_times.key_silk_cases / thread_other_cpu_time_per_frame /

FWIU it's saying that we used to spend ~0.005ms doing work on "other threads" during the key_silk_cases and now we're spending ~0.014ms.

i.e. a 9us regression on CPU usage? This CL indeed introduces a bit of work on Task Scheduler threads which I guess are in "other threads", but 9us doesn't sound dramatic at all, shall we say WontFix?

I'll try to lower the latency a bit but don't think we can do much more than that : https://chromium-review.googlesource.com/#/c/chromium/src/+/1073569 

Actually I found a way to aggressively reduce these reports in the latest PS @ https://chromium-review.googlesource.com/c/chromium/src/+/1073569.

Should solve this.

 Issue 845934  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7e7dd55cce56f643d5945f5a2dbd42d475c73e1b

commit 7e7dd55cce56f643d5945f5a2dbd42d475c73e1b
Author: Gabriel Charette <gab@chromium.org>
Date: Mon May 28 13:39:21 2018

[TaskScheduler] Slower latency heartbeat

The heartbeat is causing minor CPU usage regressions ( crbug.com/845919 )
and we're getting more reports than we need. Let's start with one
report per hour per user and increase later if we find that's not enough.

Previously we relied on the heartbeat interval being fast enough (less than 30 seconds
to not cause threads it used to be recycled (and in turn we also kept 2 or 3
threads alive per pool instead of 1 because of these).

Now we only perform a heartbeat with random traits at a time so that,
if idle, we use the existing idle thread and do not cause further churn.

R=fdoray@chromium.org

Bug:  845919 ,  810746 
Change-Id: I2bd5cab89cbdafa22ccbd31ab49d7c3c9a4fc53b
Reviewed-on: https://chromium-review.googlesource.com/1073569
Reviewed-by: François Doray <fdoray@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#562248}
[modify] https://crrev.com/7e7dd55cce56f643d5945f5a2dbd42d475c73e1b/base/task_scheduler/service_thread.cc
[modify] https://crrev.com/7e7dd55cce56f643d5945f5a2dbd42d475c73e1b/base/task_scheduler/service_thread.h
[modify] https://crrev.com/7e7dd55cce56f643d5945f5a2dbd42d475c73e1b/base/task_scheduler/service_thread_unittest.cc

Graph recovered with r562248.

Issue 845664 has been merged into this issue.