[How-to] Increasing performance by changing CPU governor and reducing swappiness

[This is a draft writeup for a candidate entry in Quick Docs - an issue for which you can find here, awaiting triage]


GNOME can be slow and laggy at times. With the onset of Wayland though, the problem has more than resolved for folks but even then, if the problem seems to have stayed back for you - the following tips might help you fix it to have an overall faster GNOME performance with smoother animations.

Changing the CPU governor

  • Before getting into modifying it, what is a CPU governor?
    A CPU governor decides how the CPU raises and lowers its clock speed in response to the demands the applications place on the system. They can help in striking a balance between performance and battery efficiency or to be inclined towards either.
  1. How do you check the list of available governors for your CPU?
    Simply execute the following command,
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
    This should list the available governors for your CPU -that you can choose from.
    Following is an example output.

  2. How do I know which governor is currently active on my CPU, should I have more than one of them?
    Simply execute the following command,
    cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
    This should display the governor that is currently enabled on your CPU.
    Following is an example output.

  3. How do I increase make the CPU perform better using the governor?
    Simply execute the following command,
    echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    Following is an example output.


    This sets all the cores to work on the performance governor and the CPU cycles would have an affinity towards higher clock limit.

    • Advantages
      • GNOME would now perform significantly faster and the animations would be smoother.
      • You would notice less artifacts on the GNOME panel and other applets that you use.
    • Disadvantages
      • The device is likely to slightly heat up due to active CPU usage and fans would be rolling.
      • There would be a slight impact on battery life if the CPU constantly stays on this governor.
  4. How do I make the battery life better using the governor?
    Simply execute the following command,
    echo powersave | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    Following is an example output.


    This sets all the cores to work on the powersave governor and the CPU cycles would have an affinity towards lower clock limit.

    • Advantages
      • The device is likely to stay cooler due to minimal CPU load and fans would not be used.
      • The battery life would stay the same for a long time if the CPU constantly stays on this governor.
    • Disadvantages
      • GNOME’s performance would be adversely affected and animations would be choppier.
      • You would notice more artifacts on the GNOME panel and other applets that you use.
  5. What other CPU governors are likely to be available on my CPU?
    The command specified in point #1 would list the available governors for your CPU but allow me to explain what each does so that you can pick the right one as per your requirement.

    • conservative - This makes the CPU stick to the lowest possible clock speed as much as possible but would raise it promptly, once a larger and more persistent load is placed on the CPU. This can strike a good balance between battery life and performance - being slightly more inclined towards battery life.
    • userspace - This allows any program to be executed by the user to decide what CPU’s operating clock speed should be. The best example is when there is a performance profile application installed by the users which needs elevated privileges to control how the CPU clock speeds scale.
    • powersave - This makes the CPU stick to the lower clock speed limit, thus saving a huge chunk of battery level and improving battery life but adversely affecting the performance as a result - so every applications would execute significantly slower and animations would be choppier.
    • ondemand - This makes the CPU boost to higher clock speeds, once a large load is placed on the CPU and slowly reduces the clock speeds once the load is removed. This can strike a good balance between battery life and performance - being slightly more inclined towards performance.
    • performance - This makes the CPU stick to the higher clock speed limit, thus increasing the performance significantly and making the animations smooth, however ends up adversely affecting the thermal performance, battery level as well as battery life (in a long run).

Reducing the swappiness value

  1. Before getting into modifying it, what is swappiness value?
    Swappiness is a property for the Linux kernel that changes the balance between swapping out runtime memory, as opposed to dropping pages from the system page cache. Swappiness can be set to values between 0 and 100, inclusive. A low value means the kernel will try to avoid swapping as much as possible where a higher value instead will make the kernel aggressively try to use swap space.

  2. Why is “reducing” the swappiness value a good idea?
    Suppose you have a system RAM with capacity of more than or equal to 16GB and a good frequency of 2400MHz or above - this should be more than sufficient to load entire programs on the memory and execute from there in most circumstances. Having a higher swappiness value in this scenario disregards all the good that the primary memory could have brought you and makes you depend on a much slower secondary memory device, as that is where the swap partition resides - thus causing a bottleneck. Reducing the swappiness value is a good idea as it would make the scheduler proactively use the primary memory as much as possible.

  3. Why is “increasing” the swappiness value a good idea?
    Suppose you have a system RAM with capacity of less than or equal to 4GB and an okayish frequency of 2133MHz or lower - this is not at all sufficient to load even browsers completely on the memory and execute from there in most circumstances. Having a lower swappiness value in this scenario adds undue load on the primary memory which is undercapable and you are likely to frequently face out-of-memory errors due to such a configuration. The increased tendency to swap pages to the secondary storage device would allow execution of larger programs (with size larger than the primary memory) and increasing the swappiness value is thus a good idea.

  4. How do I check current swappiness value?
    Simply execute the following command,
    cat /proc/sys/vm/swappiness
    This would display the current swappiness value for your system which is 60 by default for Fedora.
    Following is an example output.

  5. How do I change swappiness value?
    Open /etc/sysctl.conf with a text editor of your choice.
    For example sudo nano /etc/sysctl.conf
    Following is an example output.


    Append the following line in the file, save changes and restart your system.

    • If you have a DDR4 RAM with 8GB capacity or more and a good frequency of 2400MHz or above, add - vm.swappiness=10.
    • If you have a DDR3/DDR4 RAM with 4GB capacity or less and an okayish frequency of 2133 MHz or less, you need not make any changes.

Here’s hoping this not-so-short how-to guide would help you get better performance out of GNOME. :smile:

4 Likes

It’ll be better to quantify “slight” when making these suggestions. Otherwise, the next thing you know. you’ll have questions about why the battery is only lasting half the usual time :stuck_out_tongue:

Also, these changes will not survive a reboot, will they? I’d also add references if this is going to be a quick-doc: to the kernel docs and so on. At the moment, there aren’t any.

3 Likes

I wish I had folks to test it for me :sob:.

That is true. I think we should get this quantified before we make it enter the Quick Docs (that is if we are making it enter the Quick Docs)

I am writing a follow up to this how-to guide as a comment to this post containing the instructions to make these changes persist.

Here again, I would add references as comments below. I have apparently hit the character count limit I think.

1 Like

References

  1. AskUbuntu - Power management on Ubuntu (https://askubuntu.com/questions/604720/setting-to-high-performance)
  2. RedHat Access - What does swappiness do and how does it affect swap_tendency? (https://access.redhat.com/solutions/103833)
  3. Fedora Forum - Reducing Swappiness (https://forums.fedoraforum.org/showthread.php?319350-Reducing-swappiness)
  4. Kernel - CPU Performance Scaling (https://www.kernel.org/doc/html/v5.8/admin-guide/pm/cpufreq.html?highlight=performance%20scaling)
1 Like

Better to use authoritative sources:

etc.

Blog posts etc. are really not authoritative—any one can write them, and they’re not necessarily reviewed to check for correctness.

2 Likes

Made the correction. Thanks for marking that out.

2 Likes

I expect this will all come up at the quick-doc review eventually anyway :slight_smile:

1 Like

How to enable the performance CPU governor on startup?

  1. Navigate to
/usr/local/bin/
  1. Create a shell script file named perf-prof.sh here with the following content.
#!/bin/bash

echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
  1. Make the script executable by running the following command
sudo chmod 744 /usr/local/bin/perf-prof.sh
  1. Navigate to
/etc/systemd/system/
  1. Create a systemd service file named perf-prof.service here with the following content.
[Unit]
After=network.target

[Service]
ExecStart=/usr/local/bin/perf-prof.sh

[Install]
WantedBy=default.target
  1. Set permissions for the systemd service file by running the following command.
sudo chmod 664 /etc/systemd/system/perf-prof.service
  1. Reload the systemd daemon by running the following command.
sudo systemctl daemon-reload
  1. Enable the service which you just created
sudo systemctl enable perf-prof.service
  1. Start the service
sudo systemctl start perf-prof.service
  1. Check your current CPU governor - if it is performance, you were successfully able to set up the script.
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

You can use the similar instructions for switching up to any CPU governor of your liking on boot. Just switch the CPU governor name in the shellscript file mentioned in step #2.

1 Like

I thought just adding a kernel boot parameter is the suggested way of doing this?

1 Like

I don’t know if it’s just me but a systemd service feels a tad more safer than having those configurations in the mkinitcpio because I can disable/stop/restart/enable those configurations on the fly whenever I want even when the device is running.

I don’t think that is possible with the kernel command-line parameters. Correct me if I’m wrong but I think a reboot is most likely mandatory to make sure that the changes made are actually reflected.

What do you think?

1 Like

Remove sudo as the script is supposed to run non-interactively with administrative privileges.

In addition, there’s a GNOME Shell extension:

3 Likes

Done. :smile:

I think, it does apply for the CPUs with the command I listed. (Notice the asterisk)

That would be helpful, yes. If the extension is well-received and actively maintained, we can add it in the Quick Docs.

How does it sound @FranciscoD @vgaetera?

1 Like

Usually for laptops on battery the recommended setting is ondemand or powersave.

performance drains the battery about 2x to 4x faster. Much more than “slight”.

For performance you also want to set the turbo boost.

3 Likes

Hrm? The kernel command line parameter documentation I mentioned lists the cpufrequency scaling governor option:

        cpufreq.default_governor=
                        [CPU_FREQ] Name of the default cpufreq governor or
                        policy to use. This governor must be registered in the
                        kernel before the cpufreq driver probes.

I don’t see why a systemd service that requires a user to create a systemd file etc. is safer tbh. Why include systemd when this is all kernel stuff that’s completely unrelated to systemd? You’re just adding another place where someone may make an error.

All of this can be updated on the fly as you’ve documented, without needing systemd files, no?

In general, I’d prefer not to have this sort of thing documented—advanced users don’t need a quick doc, and we shouldn’t be suggesting non-advanced users to do this kind of thing. If a quick-doc is written up, it must start with sufficient warnings about the possible consequences of tinkering with these settings.

(I mean I consider myself an advanced user and have never felt the need to tinker with any of this even when developing or building heavy-duty packages etc.)

1 Like

Welcome back @rurban :smile:

Like I said. My 4-year old Inspiron 5577 makes it slight but I would appreciate folks who could quantify this difference.

2x to 4x might be a bit too far-fetched. Let’s wait on the quantification of the difference or better yet, I might just add in that people would want to stay connected to a power adapter when using the performance CPU governor.

That’s how I can run a script on boot. The service does its job and exits out with zero overhead. Here, take a look.

Certainly. The sole reason why I decoupled the systemd part of the guide from the actual one because I think there might be a better way of enabling the governor on boot. The service part is totally optional.

Most laptop users deal with an okayishly-responsive GNOME with choppy animations as their CPU governor is set to powersave (Intel Core users) or conservative (AMD Ryzen users) out-of-the-box and they are unaware as to why GNOME lags on them so much. To address the need of such users, I believe we should have this documented in a Quick Docs with minimal yet appropriate warnings.

Suggesting the systemd service part of the guide might not be a good idea, like you mentioned, for non-advanced users but the other parts are pretty harmless. We might not need to included warning for the first part of the guide (at all) but we definitely should if we want to suggest them the script to enable CPU governors on boot. (That script would need some more looking into, don’t you think? :stuck_out_tongue_winking_eye:)

Is this based on some evidence/data? If this is indeed the case, the workstation SIG that builds the Fedora workstation product should be notified to change the default governor etc. Making users change it and risking them breaking things should not be our first thought :slight_smile:

1 Like

Checked 3 laptops so far. Found a common pattern here.

The makers were HP, Dell (mine) and Lenovo.

Most certainly. We would want to have a deeper survey though. As much as you might say that 3 is not enough, it does form a pattern - something we would confirm by it.

Like I mentioned, the first part does not literally break stuff as a reboot would restore back the configuration like as it was before so I don’t really see a reason why they would be breaking things by following the guide here.

The second part about having the enable that configuration can be tricky (and risky) so we would want to have warnings for those wanting to implement it.

The workstation SIG, and the kernel development community do this. There’s a reason why powersave is the default. But yes, best to approach the workstation SIG, and I’m sure they’ll be happy to share their findings and discuss changes. If this does go through, it will most definitely require the change process to be followed so that the community can discuss it:

It isn’t users trying to break stuff, it’s them missing things and causing breakages. One should not assume that the target audience is well versed or advanced enough to make system level changes, especially ones that require editing system files.

2 Likes

That is true. Not every user would be seeking for better animations or fluidity at the cost of worsened battery levels. Approaching the Workstation SIG would be the first thing to do here.

(I could use some more information on this :sweat_smile:)

That is correct too. Should we add warning flags on the documentation then? (or drop it off entirely? - might help the savvy ones so I wouldn’t suggest)

1 Like