Significant Performance & Perf-Per-Watt Gains Coming For Intel CPUs On Linux Schedutil

[phoronix]

Phoronix: Significant Performance & Perf-Per-Watt Gains Coming For Intel CPUs On Linux Schedutil

Sadly not making it for the just-closed Linux 5.4 merge window but hopefully something we could see in Linux 5.5 is recent patches on "frequency invariance" in optimizing the Schedutil frequency scaling governor that will really benefit Intel CPUs and improve their performance by double digits...

http://www.phoronix.com/scan.php?page=news_item&px=Schedutil-Frequency-Invariance

[skeevy420]

For generic desktop use, I normally use scheduitl without any complaints. It pairs nicely with "x86_energy_perf_policy -t 1 -c 0-15 performance" for day-to-day tasks and I'll switch over to performance for the times I have to ensure I'm running at max frequency (games, compiles, compression, video encoding, etc). Gonna have to find out if this patches cleanly into 5.3 after clicking "Post Reply".

UPDATE:

Patches cleanly into 5.3.2, compiled just fine, and my desktop still works. Couldn't say if it's any better or worse, but it works.

Y'all can find it and the other patches I'm using with 5.3 here.

[mlau]

Intel should integrate the energy_perf_policy bits into intel_pstate itself, and only expose a knob to userspace to allow to set minimums/maximums. I.e. while on AC power it's allowed to set it to max perf on high load and limit it to e.g. "balanced" while on battery. Similarly, on idle cores it should be set automatically to lowest power allowed.

[perpetually high]

Patches cleanly into 5.3.2, compiled just fine, and my desktop still works. Couldn't say if it's any better or worse, but it works.

Compiled for me on 5.3.2 as well, failed on 5.4-rc1. Thanks for the tip on x86_energy_perf_policy (and the zstd patch!)

Question for you - so uh, how do I enable schedutil? I'm on intel_pstate at the moment and can't seem to switch. I have CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y in my kernel config as well.

[geearf]

Compiled for me on 5.3.2 as well, failed on 5.4-rc1. Thanks for the tip on x86_energy_perf_policy (and the zstd patch!)

Question for you - so uh, how do I enable schedutil? I'm on intel_pstate at the moment and can't seem to switch. I have CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y in my kernel config as well.

You have to either disable pstate or switch it to passive, if not you have no cpufreq governor.

[GruenSein]

How is this evaluation procedure of CPU load specific to Intel? If the load is never evaluated based on the CPUs maximum capability, this might apply to all CPUs which adjust their frequency based on current load.

Also, I wonder how boost states are handled, since depending on the overall load of other cores and current thermals the maximum boost state cannot be guaranteed. Basing the load state evaluation on a boost state might lead to falsely detecting underutilization, i.e., the scheduler thinks, the CPU could perform better even though it cannot in this particluar moment. I think, the most reasonable measure should be the guaranteed sustained frequency for all frequencies below this threshold. This will give a measure of the fraction of the guaranteed performance. This has to be adjusted when a cores is using boost states, though.

[skeevy420]

Compiled for me on 5.3.2 as well, failed on 5.4-rc1. Thanks for the tip on x86_energy_perf_policy (and the zstd patch!)

Question for you - so uh, how do I enable schedutil? I'm on intel_pstate at the moment and can't seem to switch. I have CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y in my kernel config as well.

I use the "cpupower" package and its systemd unit. It's configured under "/etc/default/cpupower". I'm including mine because I've added some notes from the man pages it says to reference that only contains relevant information on the perf_bias setting. On my Manjaro box, enabling either of the smp_* and mc_* settings prevents it from working so I don't use them. Using 0 on the perf_bias option is the same as doing the command I posted above.

# Define CPUs governor
# valid governors: ondemand, performance, powersave, conservative, userspace.
governor='schedutil'

# Limit frequency range
# Valid suffixes: Hz, kHz (default), MHz, GHz, THz
#min_freq="2.25GHz"
#max_freq="3GHz"

# Specific frequency to be set.
# Requires userspace governor to be available.
# Do not set governor field if you use this one.
#freq=

# Utilizes cores in one processor package/socket first before processes are
# scheduled to other processor packages/sockets.
# See man (1) CPUPOWER-SET for additional details.
# From Red Hat
# Restricts the use of power by system processes to the cores in one CPU package
# before other CPU packages are drawn from. 0 sets no restrictions, 1 initially
# employs only a single CPU package, and 2 does this in addition to favoring
# semi-idle CPU packages for handling task wakeups.
#mc_scheduler=0

# Utilizes thread siblings of one processor core first before processes are
# scheduled to other cores. See man (1) CPUPOWER-SET for additional details.
# From Red Hat
# Restricts the use of power by system processes to the thread siblings of one CPU
# core before drawing on other cores. 0 sets no restrictions, 1 initially employs only a
# single CPU package, and 2 does this in addition to favouring semi-idle CPU packages
# for handling task wakeups.
#smp_scheduler=0

# Sets a register on supported Intel processore which allows software to convey
# its policy for the relative importance of performance versus energy savings to
# the  processor. See man (1) CPUPOWER-SET for additional details.
# from "man cpupower-set"
# Sets a register on supported Intel processore which allows software to convey its policy
# for the relative importance of performance versus energy savings to the  processor.
# The range of valid numbers is 0-15, where 0 is maximum performance and 15 is maximum energy efficiency.
perf_bias=0

# vim:set ts=2 sw=2 ft=sh et:

[nuetzel]

How is this evaluation procedure of CPU load specific to Intel? If the load is never evaluated based on the CPUs maximum capability, this might apply to all CPUs which adjust their frequency based on current load.

So true, even if we have to remember this:

'Meanwhile, kernel developers are hoping for a future where Schedutil could potentially replace the other existing frequency scaling governors.'

[skeevy420]

So true, even if we have to remember this:

That quote you added is why I use it now instead of ondemand. I made the switch somewhere around 4.17 or 4.18 IIRC.

GruenSein

While I can't comment for others, on my system schedutil has no problems holding the boost frequency with or without this patch. I have the best cooling possible for my Dell workstation (OEM) and that keeps my CPUs under 65C & 75C at full load (CPU 0 has a bigger, better heat sync than CPU 1 hence the two reported highs).

[pruzinat]

Hm, I have always disabled all frequency scaling in kernel and relied on C-states, never seemed to have made a big difference (last time I measured it was like a watt on laptop and 3W on desktop as measured by intels performance counters thingy). Does scheduler & cpufreq/pstate actually make noticeable difference to how long does laptop last on battery? I always thought that power management firmware in modern laptops did most of the work. As far as desktop goes, difference between 30W and 35W draw from outlet never seemed important (my old SIPS monitor has 12k hours of backlight and ~40W draw so drop in a bucket).