@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.

Looks like this became stalled.

I'm going to suggest that the logical next step here is to (a) list which CPU governors are available, and (b) determine how a CPU governor becomes selected by default, and (c) determine precisely what the requested change is. Because so far, I do not see a clear requested change. The initial request here says "the default chosen governor is powersave (for Intel CPUs) or conservative (for AMD CPUs)" but I know this is not true because on my AMD CPU computer it is set to schedutil. Then we'd at least have a well-formed request to start with.

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.

Honestly I wonder if this might be beyond the capability of the Working Group.

CC @hadess for heads-up because this seems related to power-profiles-daemon, is that correct?

The initial request here says "the default chosen governor is powersave (for Intel CPUs) or conservative (for AMD CPUs)" but I know this is not true because on my AMD CPU computer it is set to schedutil. Then we'd at least have a well-formed request to start with.

On Intel CPUs, power-profiles-daemon doesn't change the governor, it changes the "Energy Performance Bias" or the "Energy vs Performance Hints" toggles depending on hardware support. Changing the governor to something other than powersave would mean those toggles don't do anything anymore.

I have the same question about what's being requested here, because it's not clear, and has the potential to make things worse.

Hey there,

I am the original requestor. The performance on GNOME feels laggy when the
default selected CPU governors are applied. I created this request back
when there was no implementation of power profiles, so one of the things
that I used to do was to switch over to a more performant CPU governor and
the results were immediately visible. The transitions become a lot more
smoother and the animations feel a lot more fluidic.

With the current implementation of power profiles, I do not know if such a
change is needed at all - but it certainly appears to be the software or
the configuration that happens to be holding back the GNOME experience,
rather than the actual hardware itself.

Regards,
Akashdeep Dhar

On Thu, 12 Jan 2023, 14:34 Bastien Nocera, pagure@pagure.io wrote:

hadess added a new comment to an issue you are following:
``

The initial request here says "the default chosen governor is powersave
(for Intel CPUs) or conservative (for AMD CPUs)" but I know this is not
true because on my AMD CPU computer it is set to schedutil. Then we'd at
least have a well-formed request to start with.

On Intel CPUs, power-profiles-daemon doesn't change the governor, it
changes the "Energy Performance Bias" or the "Energy vs Performance Hints"
toggles depending on hardware support. Changing the governor to something
other than powersave would mean those toggles don't do anything anymore.

I have the same question about what's being requested here, because it's
not clear, and has the potential to make things worse.
``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-workstation/issue/212

So it seems we must not change the CPU governor on Intel or power-profiles-daemon will break... OK, good thing I CCed @hadess here. Hi @hadess, is there any UI indication that the power mode options are broken when a non-powersave governor is selected? We should probably hide the power mode UI altogether (from gnome-shell and gnome-control-center) when it would be ineffective.

@t0xic0der since you created this request personally, I wonder if you see noticeable differences in the available power modes when using the powersave CPU governor. Have you tested the different power mode options? Seems like a good opportunity to check and ensure the original problem is still present and whether it can be mitigated by selecting a different power mode.

So it seems we must not change the CPU governor on Intel or power-profiles-daemon will break... OK, good thing I CCed @hadess here. Hi @hadess, is there any UI indication that the power mode options are broken when a non-powersave governor is selected? We should probably hide the power mode UI altogether (from gnome-shell and gnome-control-center) when it would be ineffective.

This is already handled.

Hi @catanzaro,

I tried reaching out to you using the internal Red Hat gchat but that doesn't seem to have worked. Anyway, I went ahead with the testing and observed that devices with low-powered APUs (notably, the laptop CPUs whose names end with a U and have a display unit) could benefit from the CPU governor's change. Also, the devices with no discrete GPU (even with CPUs whose names end with H etc.) require to rely on the CPU for both computing as well as display rendering, so GNOME having animations enabled - becomes a necessity.

I have taken my test observations from a Lenovo Thinkpad P1 Gen 3 running an Intel i7-10850H. This device does not have a dedicated GPU and as a result, has to rely on the CPU for both the computing and display rendering tasks.

• First, I enabled the Performance profile from the GNOME quick settings panel and tried switching into drawer mode and out whilst having at least, 4 windows in the same workspace. The animations were sluggish and the framerate drops were noticeable, though lesser as compared to that of the Balanced and the much worse, Power Saver profiles.

• Then, I changed the CPU governor changing tool for a spin. I switched over to the performance CPU governor and the differences were immediately noticeable. The animation of switching in and out of the drawer view whilst having at least 4 windows in the same workspace looked a lot smoother and felt a lot faster. The framerate felt very consistent too.

I took it for a spin on my desktop computer as well but as it had a dedicated GPU, the entire point of relying on the CPU to do both these tasks is moot so I didn't progress further. The animations and transitions on the desktop PC were smooth regardless of the governor active on the CPU and as the desktop CPU does not have to restrict its power usage (being plugged into the wall outlet all the time as compared to the battery-powered laptops), it most likely was not held back from performing to its potential.

To answer your question, the power profiles do help alleviate some of the sluggishness but still if one would want to get the best performance out of their devices on GNOME, switching the governor remains one of the quickest (and dirtiest, as prolonged usage under the performance CPU governor might reduce the battery life) solutions out there.

I tried reaching out to you using the internal Red Hat gchat but that doesn't seem to have worked.

Well it sort of worked, but problem was I only just now noticed it. I had sent you an email earlier in the day as well, but seems you missed that. Oh well. :)

Anyway I think the takeaway here is we need to look more seriously at this. I believe you're the first person to bring this concern to us, and it's not a topic I'm familiar with at all. But clearly Fedora's defaults are not the best choice for your hardware, and picking good defaults is half of what we do. We need to better understand the trade-off between performance and battery life before changing anything, though. And we need to figure out how to do this without sabotaging power-profiles-daemon.

Changing the CPU governor just means changing the minimum and maximum frequencies the cpufreq driver will use, so changing them to, say, performance means that you don't really control anything by changing the EPP or EPB.

For the lack of performance from the GNOME animations when using low-power mode, it's a known problem. I don't have the bug at hand, but the problem is that the CPU frequency doesn't change fast enough because it notices the spike in use too late, amongst other things.

So changing the CPU governor would just make battery life worse without fixing the root of the problems. If the performance is worse when using the "Balanced" profile in power-profiles-daemon than booting the system with the daemon completely disabled, then the problem lies with the kernel.

There are bugs about the defaults we use for the energy_perf_biastoggle, though, again, changing those won't solve the root cause.

We shouldn't change the governor unless you want to break the power profiles selection and make battery life worse.

I'll add this to our agenda for next week's regular meeting, which @t0xic0der is planning to attend. Would be great to have @hadess as well if possible.

I'll add this to our agenda for next week's regular meeting, which @t0xic0der is planning to attend. Would be great to have @hadess as well if possible.

I don't know when that meeting is. If you want me to attend, please send an invite.

Calendar entry here (contains an ical export)

Discussed today:

• Workstation WG declines to change default CPU governor
• But we do want to make sure there is ongoing work to address the performance problems discovered by @t0xic0der
• @t0xic0der is requested to report a bug to power-profiles-daemon
• @otaylor to keep an eye on the power-profiles-daemon bug report

Also apologies that it took two years to get to this. Better late than never....

This is the relevant gnome-shell/mutter discussion, in particular this comment:
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3760#note_1060444
which explains why there might be stuttering when using another cpu governor.

• @t0xic0der is requested to report a bug to power-profiles-daemon

I notice this hasn't happened yet, so I guess we are not currently tracking this problem anywhere.

I filed https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/121 as a tracking bug.

If powerprofilesctl reports anything but "intel-pstate" being used, then this bug will also be relevant: https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/107

@catanzaro,

I was occupied in the last couple of weeks in my travels to FOSDEM 2023 and
for the Fedora Council meeting. I should be able to get to create a bug
somewhere around this week.

Thanks and regards,
Akashdeep Dhar
t0xic0der@fedoraproject.org
akashdeep@redhat.com

On Fri, Feb 10, 2023 at 5:15 PM Bastien Nocera pagure@pagure.io wrote:

hadess added a new comment to an issue you are following:
``
I filed
https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/121
as a tracking bug.

If powerprofilesctl reports anything but "intel-pstate" being used, then
this bug will also be relevant:
https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/107
``

To reply, visit the link below or just reply to this email
https://pagure.io/fedora-workstation/issue/212

Hi, it looks like hadess just handled that in the comment above, so we probably don't need any more bug reports now.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/workstation/tickets/issues/212

Please continue any further discussion there.