In D10238#168497, @JoshStrobl wrote:

I'd like to see some up-to-date performance metrics on schedutil vs powersave to see if the gains in performance of schedutil (if any in reality) meaningfully negate the loss (if any) in battery life from the presumably higher clocks and changes to P-state.

Another solution I was thinking was to comment out the scheduler parts altogether so it would use to kernel defaults. They were uncommented on latest diff and after that people with TLP started to complain about performance issues.

In D10238#168508, @stalebrim wrote:

Another solution I was thinking was to comment out the scheduler parts altogether so it would use to kernel defaults. They were uncommented on latest diff and after that people with TLP started to complain about performance issues.

This seems more like an issue with the fact that CPU_SCALING_GOVERNOR_ON_AC was erroneously set to powersave rather than performance or ondemand. It wouldn't explain the issues people were getting on desktops with TLP disabled, but with TLP enabled I could certainly see why (namely on laptops, there's zero reason to have TLP on a desktop).

I'm still curious about seeing any sort of in-depth and up-to-date analysis on powersave vs schedutil though.

I have some benchmarks! Give me a moment.

https://openbenchmarking.org/result/2012156-FI-SCHEDULER18

My own testing on a Ryzen 7 3700X desktop.

I appreciate the benchmarks but I was kinda expecting the testing and metrics to be done on a laptop, running on battery, so we can get an idea on how significant the reduction is in battery life for the additional performance.

In D10238#168921, @JoshStrobl wrote:

I appreciate the benchmarks but I was kinda expecting the testing and metrics to be done on a laptop, running on battery, so we can get an idea on how significant the reduction is in battery life for the additional performance.

Ah, yeah, I can do that too-- I just happened to have those results on hand. Any particular tests you'd like me to run?

In D10238#168930, @serebit wrote:

In D10238#168921, @JoshStrobl wrote:

I appreciate the benchmarks but I was kinda expecting the testing and metrics to be done on a laptop, running on battery, so we can get an idea on how significant the reduction is in battery life for the additional performance.

Ah, yeah, I can do that too-- I just happened to have those results on hand. Any particular tests you'd like me to run?

Nothing to crazy, probably just:

1. Battery life at idle until it is RIP
2. Battery life watching a video in Firefox. Here's an example: https://www.youtube.com/watch?v=AgpWX18dby4

To shorten the battery life artificially and reduce overall test time, you could set brightness to 100%, disable dimming and locking, turn on bluetooth and wifi (even if you aren't connected to a wifi network but only on ethernet).

If you can think of any real-world example testing that doesn't take an eternity that you'd want to do instead, you're welcome to do that. It just needs to be effectively the same run-to-run to reduce any test result variance. We already have a good idea as to the performance gains when we're really hammering the CPU, but I doubt people are going to be compiling the kernel back-to-back-to-back on a laptop on battery of all things.

I hooked up my Thinkpad T 430 using Solus Plasma to a wattage meter (AC, no battery, no TLP). Then I did three tests, taking readings every 10 seconds of the power consumption.

1. 1080p video on Firefox, 2 minutes, 12 readings per governor (https://www.youtube.com/watch?v=AgpWX18dby4)

2. Idle, 1 minute, 6 readings per governor

3. 720p video on Firefox, 1 minute, 6 readings per governor (https://www.youtube.com/watch?v=B4f7qAdddvg)

4. Total average

It's not much, but hope it gives a direction.

Ran a benchmark with all available governors on my laptop on battery: https://openbenchmarking.org/result/2101089-HA-FIREFOXVI77&scalar=1

This test was run with a VP9 video streaming and playing on Firefox (using the software decoder). schedutil has a slightly higher average power draw than powersave (500 mW difference). Anecdotally, the system is MUCH more responsive with schedutil enabled. More general-use-case benchmarks to follow.

More benchmarks! https://openbenchmarking.org/result/2101098-HA-GOVERNORT78. For some reason, sensor output wasn't logged for powersave in the GIMP benchmarks.

Some interesting results here:

• Context switching, program launching, thread creation, and process creation are all identical between schedutil and performance. powersave lags behind *massively* in all four.
• In heavy loads like GZip compression/decompression and OpenSSL, schedutil and performance are roughly equivalent in both power draw and speed.
• In the GIMP test, schedutil is slightly behind performance in speed, but massively improves in power draw.
• In the LibreOffice export test, schedutil is closer to powersave in speed, and between powersave and performance in power draw.

Now time for qualitative assessment!

If you ask me, switching to schedutil FOR THIS SCENARIO is worth the increased power draw. Schedutil is rather good at managing clocks depending on load. As shown with the Firefox video benches with CPU decoding, the power draw increases by a negligible amount when not much load is applied to the system. In addition, when there is a 100% load for a period of time, that period of time is shortened by the additional power fed to the cores by an amount proportional to the increase in power draw.

Also, context switching is over twice as slow on powersave, which is NOTICEABLY sluggish.

those results are actually redonkulous!