#212 Switching default CPU governor to a more powerful one
Opened 9 months ago by t0xic0der. Modified 8 months ago

I have checked in about five to six laptops so far and I have found that any workstation installation (note that I am specific about installation and not talking about the live boot), the default chosen governor is powersave (for Intel CPUs) or conservative (for AMD CPUs). I am assuming that this must have been a decided consideration but the GNOME performance due to the said selection is exceptionally laggy.

This has been explored here https://ask.fedoraproject.org/t/how-to-increasing-performance-by-changing-cpu-governor-and-reducing-swappiness/10006 and I have also written a candidate quick-docs PR pertaining this. We should explore to see if the current CPU governors were decided upon or not, and if not so - consider switching it to a powerful one to make sure that the GNOME performance is great.

(There's an issue with the too considerable swap value too but I think I'd talk about it in another issue)

Tagging you in @ankursinha. Please don't mind. :blush:


@benzea about the cpu governor and whether a higher performance cpu policy is advisable and compatible with the other work going on with thermald and uresourced. I think a laptop on battery power probably shouldn't be set to performance. And maybe balanced_powersave or balanced_performance is indicated for desktops. I haven't messed with any of this stuff.

As for vm.swappiness, the advice to reduce it needs to be revised. Think of vm.swappiness as a biasing ratio, where values less than 100 favor dropping files and file reclaim; and values higher than 100 favor anonymous page eviction and reclaim. In the case of a spinning drive, a lower value makes some sense because page out and page in is more expensive then dropping a file page. But in the case of zram-based swap, it's unquestionably a lot cheaper and faster to swap than it is to depend on dropping file pages and reading them back in again from a disk. This definitely gets more complicated when considering the nuances of the workload. Some workloads will page out and not page those anonymous pages back in, ever or not for a long time.

So there's not a great way to game this, but certainly setting it to 10 is the opposite direction to go in considering modern kernels, storage. For SSD and NVMe based swap, it's probably equally expensive and should just be in a neutral position, of 100. But considering swap-on-zram by default, I think 120-150 is reasonable.

Keep in mind anonymous pages cannot be dropped. They are either stuck in memory at 100% of their size, or they're compressed in zram-based swap and thus 50% or less their original size and therefore freeing up that much memory. We want things to swap in this case. If it turns out the workload is filling up all of this zram device's swap, that suggests increasing the size of the zram device before it means reducing vm.swappiness. Or in more extreme workloads with underprovisioned hardware, adding a supplemental swapfile or swap partition.

I would be pretty surprised if the CPU governor selection results in a noticeable impact on GNOME performance. That would most likely indicate a performance bug in GNOME that should be fixed there, right?

I think we should prioritize battery life. I guess we could reconsider if there is hard data to support that, but I don't see any here.

One thing that is important to realize here is that when you select "powersave"/"performance" on a vaguely recent (last 10 years) Intel CPU, the decisions aren't normally made by the kernel's powersave governer - instead this controls how the CPU is configured (https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_pstate.html), and the CPU itself does the work of changing p-states. In this mode, powersave vs. performance just does coarse-grained setting of the "EPP" knob (and more fine-grained setting is available by other sysfs attributes.)

I do think that it's possible that the CPU governor would have subtle effects on the smoothness of desktop behavior. There are some situations that are tricky to get right:

  • If rendering frames has some CPU work, then some GPU work, then you may want to get the CPU work done as quickly as possible, even if you are on average only using 25% cpu (or whatever). This is the basic problem that originally inspired "gamemode" - to change the CPU governor while games are running.

  • When you start an animation, you want to get the GPU and CPU ramped as quickly as possible and avoid having slow warm-up frames.

But the latter effect, in particular, is quite subtle, and without instrumentation to actually measure the frame rate in known test situations, it's going to be very hard to know if tweaking knobs or changing algorithms makes any difference.

I would be pretty surprised if the CPU governor selection results in a noticeable impact on GNOME performance. That would most likely indicate a performance bug in GNOME that should be fixed there, right?

Not really. I have made these observations across various versions of GNOME getting shipped with Workstation and have found that there's an evident sluggishness in terms of interactivity when the governor is left set at whatever it is at. I do understand that laptops, being battery-operated devices, should prioritize longevity but not really, at the cost of performance. A more powerful governor is requested or maybe an automated option to switch between them is recommended as even when the devices are plugged into power, the governor stays the same which is awkward.

I think we should prioritize battery life. I guess we could reconsider if there is hard data to support that, but I don't see any here.`

Five to six laptops over a period of about six months (basically 32 and 33) might not be much to go on with but I think, we should survey it more to see if people are actually getting impacted due to this and how positive the changes can be when the governor is switched to a more powerful one.

If rendering frames has some CPU work, then some GPU work, then you may want to get the CPU work done as quickly as possible, even if you are on average only using 25% cpu (or whatever). This is the basic problem that originally inspired "gamemode" - to change the CPU governor while games are running.

A good number of users who are on laptop devices might not have a dedicated GPU or maybe decide against using it due to the relative difficulties in setting up the drivers (and other such reasons) due to which the CPU acts like an APU and does the "GPU workload" by itself. GNOME employs certain transitions and bezier effects that are more CPU intensive when put to play - most notably, when moving the mouse pointer to the top-left corner - the overview menu appears and when the grid icon is clicked on, the icons fly in. These animations have notable sluggishness when on either powersave (Intel) or on conservative (AMD).

When you start an animation, you want to get the GPU and CPU ramped as quickly as possible and avoid having slow warm-up frames.

This is nearly impossible with governors of the likes of powersave and conservative due to their affinity to the lower limit of the clock cycle. Something like performance or ondemand, should be able to alleviate this issue by attaining a "ready" state.

But the latter effect, in particular, is quite subtle, and without instrumentation to actually measure the frame rate in known test situations, it's going to be very hard to know if tweaking knobs or changing algorithms makes any difference.

The observations I have made so far have been with naked eye but it did require me to first, face the sluggishness for a considerably longer time (like for about a week), and then switch governors to see if I can actually appreciate the apparent smoothness which comes as a result. I was surprised that even my i5-7300HQ disappointed me with the default settings.

Another complaint about CPU governor here. Looks like the issue may or may not already be fixed upstream. Further investigation required.

This topic is somewhat beyond the expertise of the Working Group.

Speaking only for myself, I'm much more interested in maximizing battery life than performance. So, naively, a governor named "powersave" sounds good to me. But if the CPU governor choice results in a noticeable desktop responsiveness difference -- and I understand you claim it does -- then I would say we've gone too far in the direction emphasizing battery life. So my priorities would be: responsiveness > battery life > performance ("bandwidth")

I have checked in about five to six laptops so far and I have found that any workstation installation (note that I am specific about installation and not talking about the live boot), the default chosen governor is powersave (for Intel CPUs) or conservative (for AMD CPUs).

I've checked my AMD desktop and an Intel laptop. In both cases, I see:

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor 
schedutil

The above complaint states that the default governor has changed from 'ondemand' to 'schedutil'. I haven't seen anything about 'powersave' or 'conservative'. Do you know what's really going on here? Because I don't. We should understand how the default governor is chosen before scheduling this for a meeting.

Fedora 33 (5.10.15-200.fc33.x86_64)

$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_{driver,governor} 
intel_pstate
powersave

with the caveat above the scaling_driver is the controlling thing here and the classic powersave code is not running.

Hey @catanzaro, I understand the reason behind being inclined to maximising the battery life of mobile computing devices which does seem to be the right thing to do for spins with XFCE, LXQt, LXDE, i3 etc but with those having KDE, Deepin and for the workstation (having GNOME) - this setting is an absolute no-go due to the fact that it brings about a lot of stutters and deferred responsiveness to action. This slowdown would certainly lead to a loss of productivity and experience which definitely should not be more important than extending battery life.

I wrote one application which you can find here https://github.com/t0xic0der/switcheroo, to help me quickly switch between various CPU governors and these are the outputs on-boot from Fedora 33 installations.

(Intel i5-7300HQ Dell Inspiron 5577)

[t0xic0der@ToxicDragon Applications]$ ./switcheroo-v0.1.0-amd64 -list
[ ✓ ] Available CPU governors were successfully read
      performance
      powersave
[t0xic0der@ToxicDragon Applications]$ ./switcheroo-v0.1.0-amd64 -crnt
[ ✓ ] powersave is the currently selected CPU governor

(AMD Ryzen 5 3400G HP Pavilion)

[soumadeepdhar@PAVLO bash]$ ./switcheroo-v0.1.0-amd64 -list
[ ✓ ] Available CPU governors were successfully read
      conservative
      ondemand
      userspace
      powersave
      performance
      schedutil
[soumadeepdhar@PAVLO bash]$ ./switcheroo-v0.1.0-amd64 -crnt
[ ✓ ] schedutil is the currently selected CPU governor

I believe that there's a picked governor which attains prevalence due to the fact that maybe it is expected to be in the default behaviour without having regards to switch automatically when the load dynamically increases.

"is an absolute no-go due to the fact that it brings about a lot of stutters and deferred responsiveness to action"

Obviously, the vast majority of people running Fedora have not switched their cpufreq settings away from the default. So I'm not sure it's productive to describe the default behavior as "an absolute no-go" - it's apparently workable for most people - though it's certainly interesting if switching it produces smoother behavior and better responsiveness!

Our goal is, of course, to get good smoothness and responsiveness and good battery life. Getting there involves engaging with the cpufreq maintainers in the kernel - and being able to show them hard data rather than just subjective experience. So, we'd need to figure out how to measure both smoothness/responsiveness and battery life.

I was working on some projects in this area years ago:

https://blog.fishsoup.net/2014/10/23/perf-gnome-org-introduction/
https://blog.fishsoup.net/2015/01/15/gnome-battery-bench/

The automated-testing aspect of perf.gnome.org is entirely dead and gone at this point, but it should still be possible to run gnome-shell-perf-tool on an machine and look at the results. @ofourdan was working on it a year ago: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/941 and might be able to help out if someone wanted to try that out.

Login to comment on this ticket.

Metadata