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

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


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

Android Nexus6 WebView Perf

rendering.mobile - Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/12de8e69e40000

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

Reland "Enable Perfetto by default for all telemetry tests" by oysteine@chromium.org
https://chromium.googlesource.com/chromium/src/+/3bb24369bef996b43b2d2711f0033ba472f779ea
thread_raster_cpu_time_per_frame: 0.6145 → 0 (-0.6145)

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

Benchmark documentation link:
  https://bit.ly/rendering-benchmarks

Note oysteine@: this metric has gone up from zero, later (version range: 604426 - 604489). However, it's still signifficantly different (30% lower) than the metric value before the Perfetto CL. Could you please take a look?

#3: This is measuring trace event time on worker threads that don't have a current messageloop and hence non-Perfetto tracing needs to grab the global TraceLog lock to add each trace event, as far as I can tell that's what's causing this metric shift (no such lock with Perfetto).