I need your best performance tips!

Hey :slight_smile:

I have a 2+ year old laptop with Fedora, I’ve updated it over a few releases. Things have gotten very slow. It’s an i7 with 32 GB RAM and a 1TB SSD (it’s a thinkpad yoga carbon gen 6.) I’m not really sure why the performance has gotten so poor. But I’m backing it up now and trying to figure out how I might start “from scratch” and get it to be more performant.

Does anybody have tips for performance? E.g. how do you lay out your partitions for peak performance? Should I stick with Fedora workstation or try silverblue? Any and all recommendations greatly appreciated.


Are you encrypted? The cryptsetup defaults aren’t great for SSDs.

$ sudo cryptsetup status luks-<redacted>

  type:    LUKS2
  cipher:  aes-xts-plain64
  keysize: 512 bits
  key location: keyring
  device:  /dev/sda3
  sector size:  512
  offset:  32768 sectors
  size:    973412352 sectors
  mode:    read/write
  flags:   discards no_read_workqueue no_write_workqueue

I had to add those flags:

$ sudo cryptsetup --allow-discards --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh luks-<redacted>

Based on:





Nope, I’m not encrypted. But this is a great tip :slight_smile: Thank you!

Well, that’s kind of alarming! I’ve got two weak Ivy Bridge systems on SSD I’ve been upgrading since f34, and they’ve only gotten more performant over the years. I’d be on the lookout for hardware gremlins.

I’d say Atomic Desktop seems to be very “polarizing”. Most people seem to either love it or hate it. Here’s a recent discussion:

If it is just slow when using the web browser, you might try clearing all the cookies. Mine was running slow at one point and I was amazed at what a difference that made.

Other than that, maybe just check what you have running in the background and try to reduce it as much as possible. systemctl status gives a pretty good overview of what is currently running on your system. There might be things in ~/.config/autostart that you don’t need running all the time and you can remove.

I’ve also uninstalled a few packages that added files to /etc/xdg/autostart (use rpm -qf <path-to-file> to see what package put the file there). But nothing there should really be slowing your system down (other than maybe that tracker-miner thing, but whether you can live without that just depends on how you use your system). Don’t try to uninstall tracker-miner. Unfortunately, too many things depend on it. If you want to disable that, the way to do it is to “mask” its services. This is what my ~/.config/systemd/user directory looks like:

[/home/gregory]$ ls -al ~/.config/systemd/user/tracker-*
lrwxrwxrwx. 1 gregory gregory 9 Dec  6  2020 /home/gregory/.config/systemd/user/tracker-extract-3.service -> /dev/null
lrwxrwxrwx. 1 gregory gregory 9 Dec  6  2020 /home/gregory/.config/systemd/user/tracker-extract.service -> /dev/null
lrwxrwxrwx. 1 gregory gregory 9 Dec  6  2020 /home/gregory/.config/systemd/user/tracker-miner-fs-3.service -> /dev/null
lrwxrwxrwx. 1 gregory gregory 9 Dec  6  2020 /home/gregory/.config/systemd/user/tracker-miner-fs-control-3.service -> /dev/null
lrwxrwxrwx. 1 gregory gregory 9 Dec  6  2020 /home/gregory/.config/systemd/user/tracker-miner-fs.service -> /dev/null
lrwxrwxrwx. 1 gregory gregory 9 Dec  6  2020 /home/gregory/.config/systemd/user/tracker-miner-rss-3.service -> /dev/null
lrwxrwxrwx. 1 gregory gregory 9 Dec  6  2020 /home/gregory/.config/systemd/user/tracker-miner-rss.service -> /dev/null
lrwxrwxrwx. 1 gregory gregory 9 Dec  6  2020 /home/gregory/.config/systemd/user/tracker-store.service -> /dev/null
lrwxrwxrwx. 1 gregory gregory 9 Dec  6  2020 /home/gregory/.config/systemd/user/tracker-writeback-3.service -> /dev/null
lrwxrwxrwx. 1 gregory gregory 9 Dec  6  2020 /home/gregory/.config/systemd/user/tracker-writeback.service -> /dev/null
lrwxrwxrwx. 1 gregory gregory 9 Dec  6  2020 /home/gregory/.config/systemd/user/tracker-xdg-portal-3.service -> /dev/null

I think I created all those with something like systemctl --user mask tracker-<whatever>.service.

There are also a few things that can go off from time to time via systemd “timers” and which can cause your system to slow down a bit as they do their thing. You might check /etc/systemd/system/timers.target.wants to see if there is anything there. The worst of those is the dnf-makecache.timer. I disable that on my systems by adding metadata_timer_sync=0 to /etc/dnf/dnf.conf.

Beyond all that, about all that I can think of that would be left that might slow your system down would be either something wrong with your filesystem (e.g. Btrfs "discard storm" on Fedora? - #20 by vwbusguy but I think that has been fixed) or something amiss with your network configuration (e.g. if your primary DNS server cannot be reached and it waits for that one to timeout before trying the next server).

Depending on how severe the problem is, you might want to try running top or iotop when the system is being slow to try to spot what is causing the problem.

If you want to really fine tune, Kickstarts are always nice to use. They give very fine grained control over installed packages, systemd services, users, groups, that sort of thing. Might also be worth considering using a different desktop environment(I assume you’re using Gnome based on your phrasing and language), I use Plasma and it’s very performant, but that’s anecdotal and it’s down to your personal preference. If you like I can share my kickstart here and some basic instructions if you don’t already know about it.

As for your question about Workstation vs silverblue, as far as I could tell using both, there’s no noticeable performance difference between the two. Imo that decision mostly comes down to how much you like to mess with your Root fs and flatpaks, I like having very easy access to modify the Root fs so I don’t use the immutable variants. To be quite honest I believe you’ll see some performance dip if you use flatpaks instead of rpms on either version(but silverblue pushes you more towards flatpak than workstation does).

Another tip, your CPU is 1 generation behind the efficiency/performance core changes, which I believe makes it more likely to thermal throttle(it gets hot then it gets slow to cool down). I have an i7-1260p which is supposed to be more power efficient than your CPU, but it thermal throttled a lot before I started using this system: I use a little powersave script(it requires kernel-tools package to be installed) saved as /usr/local/sbin/powersave

cpupower frequency-set -g powersave -u 2.4GHz
cpupower set -b 15

and a little systemd service saved as /etc/systemd/system/powersave.service

Description=Set powersave governor at startup.



I also have a couple system76 specific commands I edited out, I think you should be able to substitute for lenovo or desktop environment specific commands, but it basically just set charge thresholds and set the battery driver to the battery saver profile.

I don’t think you’ll see any real gains from partitioning or anything like that(maybe some, but I doubt any noticable), but if you want to go down that route, ext4 is reliable and doesn’t use filesystem compression meaning it should use less CPU than something like btfs. But what I do know for a fact is that my fans barely get used anymore and I rarely if ever thermal throttle(I have to be using virtual machines or playing minecraft with really high settings) after switching to my powersave script.

I’m pretty sure there’s more that I know I just can’t remember right now, hopefully what I did tell does help though :slight_smile:

Edit: might also be down to driver/firmware issues, might be worth trying RPMFusion to get some. I know RPMFusion-nonfree has an Intel driver(intel-media-driver) which I need for my iGPU, and I believe should work good for your iGPU as well if I’m not mistaken.

I’ve found bpytop to be a useful tool for finding out what might be eating up resources when things lag. If you see the systemd tracker-miner service show up, that can really bog down some systems. It’s safe to disable and I’ve done so on a few of my systems whenever it’s become an issue. It’ll likely show up in top/htop/btop/bpytop if it is. iotop can also be helpful for finding out what’s eating up your disk IO.

The next thing I would suggest is checking out what services are enabled by default that might not need to be and/or checking if you have containers running in the background you may have forgotten about. The latter compelled me to write a GUI hook for myself once to remind me about them :sweat_smile: . But if you don’t run VMs super often, then disabling libvirtd in startup and just enabling it when you need to run a VM, etc., can help limit background resources.

If you’re already using the default btrfs then repartitioning isn’t likely to help since /home, etc. are subvols of root. There was a change to asynchronous trim recently that shouldn’t impact most users, but can impact some older SSDs, so setting nodiscard in fstab and putting fstrim on a weekly cron could help if you believe it’s FS bound.

1 Like

Hi there,

Intel CPUs usually default to the powersave governor, which unfortunately stays put even when your laptop is connected to the wall. Try switching the governor to performance and see if it helps.

Here’s a nifty tool I wrote some years back when facing a similar issue.

Some documentation about what the tool does and how it does that.

1 Like

I have a 9+ year laptop, which was high-end at the time - and it runs very snappy today. I have done a good share of cleaning/customizing/securing so you might want to start ‘turning off’ and excavating things you don’t use/need and turning on/installing things you actually should have.

There are some very basic important security settings that must be turned on in kernel, for example. I would start there. It meant compiling kernel myself and was an involved process. And definitely encrypt everything.

  • Check software you installed in the meantime and kick out what you don’t need.
  • Same with cache of most kind.
  • You can try out some new disk mount options in fstab entries, like noatime (if you don’t have it already)
  • You might re-balance the FS (e.g. for BTRFS, after years of heavy unbalanced usage)

Last but not least:
You may consider re-install. It is good for one thing - during the years of Fedora development, not only the software evolves, but it’s configuration too. During updates, the existing user configuration is preserved, instead of the newer, better, to be applied.
Re-install may provide you the current, up-to-date, collection of software and configuration that is considered the best we have now.

I actually wrote a systemd service to set that on my laptops:


1 Like

OK, these are rather techy and filesystem related, but they do affect your desktop experience. IMHO, they should be enabled by default, but I think they still aren’t. (Please correct me if I’m wrong! :grin:)

You can use Fedora as a desktop user for a while before hitting these problems, but they’re there, lurking, if you use encryption (first section) or have large and/or relatively slow storage devices (second section).

Thankfully, some things like btrfs compression and zram are already enabled, as of a few Fedora releases ago. Both help with performance. (Compression takes a little bit of CPU, but it is optimized and speeds up writes to and reads from storage and is a great tradeoff. Zram generally “doubles” RAM by having a compressed swapfile in memory on-demand… It not only gives you the appearance of more available RAM, it also avoids hitting a much-slower swapfile on disk or having apps give up and crash.)

Discard/trim on SSD on LUKS (encryption)

One thing that made a gigantic difference for me was enabling trim. Without it, all writes would bog down the system, and the UI would feel super slow. But I had been using Silverblue for a while already before finding this out (the hard way).

I’m not sure if it’s still the case, but Silverblue (and perhaps Fedora Workstation too) doesn’t set up trim on SSDs by default when you use LUKS. There are a few ways to work around this; I used the following:

sudo cryptsetup --allow-discards --persistent refresh /dev/mapper/luks*

The alternative method I’m aware of is @ Speed up a LUKS-encrypted Fedora Silverblue by enabling TRIM | Notes where they use a kernel boot command attribute. (Which, in Silverblue, is modified using rpm-ostree kargs by-the-way… no messing around with grub config files and commands, thankfully.)

If you’re not sure if you have the ability to use discard on SSD, you can run this and it’ll try to run trim and it’ll omit anything that doesn’t support it:

sudo fstrim -va

Additionally, Fedora has a fstrim timer. You can make sure it’s enabled with systemctl status fstrim.timer. If it’s active, then that’s great. If not, then run sudo systemctl enable fstrim.timer — but it’ll only actually trim devices that it can. (So you’d need to fix above if there’s an issue.) Having the timer enabled means you don’t have to run anything manually. I think having the timer on is default on Fedora, but it’ll basically do nothing without trim/discard support enabled for your SSD.

Block group tree for btrfs

The Linux kernel has had an block group tree for btrfs since 6.1. This lets btrfs devices mount more quickly. It probably matters the most with spinning disks and raid, but is likely beneficial for everything. While it’s a mkfs setting (and Anaconda should — but probably doesn’t yet — support it), you can convert existing btrfs partitions with a command like this (adjusted to the actual device instead of /dev/sdX):

btrfstune --convert-to-block-group-tree /dev/sdX

(This can take a minute or two. It’s not a super long conversion, but it’s not instant.)

For my use with 2 spinning disks in btrfs raid1, it changed the mount time from about half a minute to just a second or two. It probably won’t be that dramatic for most storage for most people, however.

There are a lot of great tips here. I wonder if they are appropriate for the Silverblue documentation.