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

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


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

mac-10_12_laptop_low_end-perf

media.desktop - Benchmark documentation link:
  None

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

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

Make browser UI to use OOPR as well when OOPR is enabled. by penghuang@chromium.org
https://chromium.googlesource.com/chromium/src/+/392cff8628eed1ce42f41362d2328f60768e2ce5
cpu_time_percentage: 0.1154 → 0.129 (+0.0136)

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

Benchmark documentation link:
  None

I think OOPR is enabled by default on Mac, so this CL will enable the OOPR for the browser UI.

Hi enne@, do you have any idea why OOPR will regress the cpu_time_percentage? Is it acceptable? 

What is cpu_time_percentage_avg? I'm not sure I understand what that metric is.

Looking at: https://chromeperf.appspot.com/group_report?rev=603119

Looking at all of these, I'd characterize this as:

Regressions:
* cpu_time_percentage_avg
* queuing durations (~3, with one progression)

Progressions:
* time to first (contentful) paint (mostly? one regression?)
* time to first audio
* mean frame time
* raster total cpu time
* all total cpu time

All over the place:
* memory (+/- 800k)

I'm not sure I understand what cpu_time_percentage_avg means here.  I usually look at total cpu time.  If mean frame time goes down, does cpu time avg go up?


I've seen queuing duration regressions before, however this was because the renderer raster process might have work that can't be interrupted on the gpu main thread that takes longer (i.e. shader compilation), whereas previously we could interrupt after a single shader compilation.  I don't think that's true here, though.

 Issue 899911  has been merged into this issue.

Assign it to OOPR owner enne@

My experience has been that we need to take CPU measures with a tablespoon of salt because the CPU time (at least on Linux) does not take into account the CPU frequency. I believe that many of our CPU metrics correspond to utilization instead. What this means is that if you more evenly distribute the load and the CPU frequency drops, your utilization goes up and you get a "regression".

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=892147 to this issue on Linux.

I will quickly see if I can repro this on Linux with the appropriate flags (--enable-oop-rasterization --force-gpu-rasterization --enable-gpu-rasterization --enable-features="UiGpuRasterization"). If it repros on Linux, I will try a different governor and see if clock frequency is at play.

I found this (https://cs.chromium.org/chromium/src/docs/speed/benchmark/harnesses/power_perf.md?rcl=c2b9274234afef409f22327304907453267ff50e&l=11) definition of cpu_time_percentage_avg:

This metric measures the average number of cores that Chrome used over the duration of the trace.

This metric is enabled by adding `'cpuTimeMetric'` to the list of TBM2 metrics in the benchmark's Python class.

If we dig a little bit deeper, we get this comment on cpuTimeHist (https://cs.chromium.org/chromium/src/third_party/catapult/tracing/tracing/metrics/system_health/cpu_time_metric.html?rcl=d1eeca86af6e45a61f88964e085ed4745c8570ec&l=78)

    cpuTimeHist.description =
        'Percent CPU utilization, normalized against a single core. Can be ' +
        'greater than 100% if machine has multiple cores.';

Here is media.desktop/video.html?src=crowd.ogg&type=audio run 3 times on Linux.
The first run should say performance, not head. We see huge difference in metrics between performance and powersave governor, showing that it is not taking clock frequency into account.

There is a slight regression enable UI OOPR with powersave. A slight improvement enabling UI OOPR with performance.

I will rererun with 10 tries to see if that washes out more noise.

Deleted: 3-runs.png 32.7 KB

	3-runs.png 32.7 KB View Download

I re-ran on Linux with 10 runs, and I get different results:

With performance governor, there is no difference between UI GPU raster (revert) and UI OOPR (head). With powersave governor, we see and improvement with OOP-R.

I don't know how to set the CPU frequency on OSX. A quick google search and I came up empty handed. But given how this metric is affected by changing clockspeed, I'd ignore it.

Marking WON'T FIX for now. Feel free to reopen.

Deleted: 10-runs.png 41.4 KB

	10-runs.png 41.4 KB View Download

Oh, and relevant commands for gLinux governor are:

sudo cpupower frequency-set --governor powersave
sudo cpupower frequency-set --governor performance
cpupower frequency-info

Thanks for all the analysis!