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

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


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

linux-perf

power.desktop - Benchmark documentation link:
  https://bit.ly/power-benchmarks

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

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

Use SharedImage for HUD layer and one copy raster by backer@chromium.org
https://chromium.googlesource.com/chromium/src/+/e29d023ec416e0931584cb4c6daaa478cd36b478
0.06604 → 0.08032 (+0.01428)

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

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

Looking....

I am not able to repro locally.

I ran the power.desktop/instagram with --pageset-repeat=5 and additional trace categorys "cc,gpu" to wash out noise and get more info. The difference in cpuTimeMetric is slight: 64.4 ms vs 66.2. Morever, it's slightly faster without my CL than without it.

I'll try some other regressed stories.

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/15272438e40000

Kicked off another bisect. Could just have been a bad bisect.

I believe that the bisect is correct.

I did a bit more testing. If I only use the "toplevel" trace category, then the problem is reproducible. If I add additional categories ("cc,gpu"), the problem doesn't reproduce. Moreover, the regressed metric (cpuTimeMetric_duration) is better with more trace categories! (see attached screenshot). The other measures of CPU usage increase with the additional trace categories.

I don't know what is going on here. I can only hypothesize that we are on some sort of CPU frequency scaling threshold and that frequency scaling isn't captured by this test. This is consistent with two observations:

(1) adding more load (trace categories) helps: maybe it's kicking us into a new scaling threshold.

(2) my CL moved some small amount of work from CC impl thread to background worker threads. That may changed the scaling of the cores that the threads are running on.

I'm not sure I can debug this further (e.g. without at least more tracing). I suspect no real regression.

Deleted: results.png 92.8 KB

	results.png 92.8 KB View Download

I found out how to disable CPU frequency scaling. Will rerun.

With disabled CPU scaling, my CL actually improves things (see attached). I don't believe this either, but it does suggest that the test bot is not disabling CPU scaling or accounting for it.

Marking as WontFix (can't reproduce).

Perhaps someone could file a separate bug to disable CPU scaling on these bots? Or get a real measure of power consumption.

Deleted: no-scaling.png 51.1 KB

	no-scaling.png 51.1 KB View Download

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

Use SharedImage for HUD layer and one copy raster by backer@chromium.org
https://chromium.googlesource.com/chromium/src/+/e29d023ec416e0931584cb4c6daaa478cd36b478
cpu_time_percentage: 0.1493 → 0.178 (+0.02878)

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

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

tdresser@: I filed https://bugs.chromium.org/p/chromium/issues/detail?id=892147 to the CPU frequency scaling issue. Could you check that I got the component right? If it's possible to disable scaling on the linux-perf bot, this small config change could reduce flake and give more accurate numbers.

Thanks.

 Issue 892842  has been merged into this issue.