Intel P-State Driver Preparing To Migrate From "Powersave" To Passive Schedutil Default

[phoronix]

Phoronix: Intel P-State Driver Preparing To Migrate From "Powersave" To Passive Schedutil Default

It looks like in the next one or two kernel releases we could see Intel transitioning their CPU frequency scaling governor default from the long-standing powersave to the modern schedutil governor. It's now believed schedutil should be at least as good as powersave...

http://www.phoronix.com/scan.php?page=news_item&px=Intel-P-State-Schedutil-Def

[Linuxxx]

Let me take this opportunity to quote myself here (https://www.phoronix.com/forums/foru...66#post1123766):

09-05-2019, 09:07 PM
Anyway, my prediction is that by 2021, we all will be using schedutil!
I really wonder what the opponents will be doing then...

Looks like I was already too pessimistic back then!

Anyhow, what I would like to see is more experimentation by the INTEL developers around the value of:

/sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us

Currently, INTEL sets the number to 500, which provides huge latency benefits over the (insane) ACPI default of 10000! [AMD users are "enjoying" this default setting right now with Arch Linux & Manjaro!]

However, what ANDROID does seems to be the most sensible approach -> simply setting this knob to 0!
This way, your Linux-based smartphone is able to reach the lowest latency possible & be able to rival APPLE's so-highly-regarded iOS!

I am already successfully using schedutil with this configuration on my own systems, so maybe, just maybe You & the INTEL developers might want to try it out, too!

[cynic]

I wonder if this will fix this long standing bug https://bugzilla.kernel.org/show_bug.cgi?id=109051 or if it is orthogonal to it

[bogdanbiv]

I hope this improves the state of battery life in Linux based systems. My empiric observation show that not only on Linux battery drains faster, but also after a year my laptop batteries are not charging fully. I find this bug hard to address since reproducing it requires a large setup (for battery measurements)... this isn't the proper place to discuss bugs, is it?

[RussianNeuroMancer]

I wonder if this will fix this long standing bug https://bugzilla.kernel.org/show_bug.cgi?id=109051 or if it is orthogonal to it

Is it still reproducible for you on Linux 5.5?

[cynic]

Is it still reproducible for you on Linux 5.5?

yes! but it could take several days

[Zan Lynx]

I hope this improves the state of battery life in Linux based systems. My empiric observation show that not only on Linux battery drains faster, but also after a year my laptop batteries are not charging fully. I find this bug hard to address since reproducing it requires a large setup (for battery measurements)... this isn't the proper place to discuss bugs, is it?

Have you done any extra power tuning? My Dell XPS gets 5 to 8 hours running Fedora 31. I've made many of the powertop suggestions permanent, and disabled the Nvidia 1050 Ti that's in there because I never use it in Linux.

Heck, with the display off and my user session hit with SIGSTOP it will run for 30 hours. It's basically running NoHz, minimum wakeups, all USB and PCIe devices in power-off, etc.

As for the batteries not charging fully thing? That's nothing to do with Linux. That's just Lithium Ion facts of life. After three years you'll be lucky if they're still 80% good.

[stormcrow]

Have you done any extra power tuning? My Dell XPS gets 5 to 8 hours running Fedora 31. I've made many of the powertop suggestions permanent, and disabled the Nvidia 1050 Ti that's in there because I never use it in Linux.

Heck, with the display off and my user session hit with SIGSTOP it will run for 30 hours. It's basically running NoHz, minimum wakeups, all USB and PCIe devices in power-off, etc.

As for the batteries not charging fully thing? That's nothing to do with Linux. That's just Lithium Ion facts of life. After three years you'll be lucky if they're still 80% good.

Not just Li-ion facts of life. Most batteries don't last more than 2-3 years, even long life automotive lead-acid batteries guaranteed for 5 years often start failing after 3 years. That's usually why they're prorated between 3-5 years instead of full replacement.

[cybertraveler]

Let me take this opportunity to quote myself here (https://www.phoronix.com/forums/foru...66#post1123766):


Looks like I was already too pessimistic back then!

Anyhow, what I would like to see is more experimentation by the INTEL developers around the value of:

/sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us

Currently, INTEL sets the number to 500, which provides huge latency benefits over the (insane) ACPI default of 10000! [AMD users are "enjoying" this default setting right now with Arch Linux & Manjaro!]

However, what ANDROID does seems to be the most sensible approach -> simply setting this knob to 0!
This way, your Linux-based smartphone is able to reach the lowest latency possible & be able to rival APPLE's so-highly-regarded iOS!

I am already successfully using schedutil with this configuration on my own systems, so maybe, just maybe You & the INTEL developers might want to try it out, too!

Is that latency setting one that governs how long it takes for the kernel to wake up after there is no more work to do? IE the kind of setting that benefits sound engineers and potentially some gamers.

[Linuxxx]

Is that latency setting one that governs how long it takes for the kernel to wake up after there is no more work to do? IE the kind of setting that benefits sound engineers and potentially some gamers.

The way I understand it, this knob of schedutil controls the time that has to pass until the frequency of the CPU will be changed to react to a change in system load (e.g. Your game suddenly starts to compile some shaders).
Naturally, this means the higher the number, the higher the latency times! (e.g. Your CPU is downclocked because You are in a menu inside a game, then You quit that menu and suddenly encounter a new type of enemy with a new type of shader that needs to be compiled, but schedutil doesn't ramp up the clocks just yet, since, You know, the necessary time between frequency changes as defined with >>rate_limit_us<< hasn't passed just yet.)
Therefore, the lower the number, the lower the latency times!

And since I already mentioned, Android with schedutil uses the value of 0 for this setting, which makes absolutely sense:
They are competing with Apples' iOS, which for the majority of people seems like a super-optimized OS, because it can draw its UI animations so smooth.
And then remember older versions of Android, where the UI was lagging because the CPU was not reacting fast enough to a user tapping the screen.

Schedutil was developed because of exactly this reason - namely to provide the lowest latency possible, which simply isn't possible with any other governor in Linux.
But to then cripple its functionality by setting an arbitary number that forces it to wait for an arbitary amount of time until it can change the CPU frequency simply makes no sense to me! (Like Arch Linux & Manjaro which do make use of schedutil by default on AMD systems, but leave the default value of 10000(!) untouched. At least Intel is wise enough to reduce the number considerably to 500.)

Speaking of AMD, it would be cool if they could mention an ETA on when they are planning to finally mainline their Zen CPU driver into Linux!
I had already asked bridgman about it, but he doesn't seem to care (just like the rest of AMD).

Anyway, what is definitely clear though is that schedutil is the future of Linux, with all of the other governors getting ripped out eventually...

Low-latency for the masses FTW!