KDE Multimedia edition is laggy

To whom it may concern: Hello

So when I first installed Garuda (KDE Multimedia edition), everything was super fast and snappy. At some point, 2 months after install, I noticed some issues appearing, latte dock would crash often, UI became less responsive.
Now I often get the laggy UI issue and have confirmed it's almost always when there's writes to the root disk. The disk is a PCIE4 NVME SSD capable of 5GB/s, that was new when I first installed Garuda.
I set swappiness to 0 as I have 64GB RAM, but that did not fix it.
Cpu usage is normal during these laggy moments. I notice btrfs-cleaner being active with iotop, when doing writes. Even small writes such as downloading a torrent @ 500kB/s can cause some laggyness, like the Application Dashboard taking writing input with great delay, and taking ~10 seconds to show results. alt+tab usually works okay during these laggy moments, but switching apps with latte dock is impossible (it doesn't pop up in time). Doing heavy writes like moving files from one ssd to the / drive causes more serious lock-ups.

I had these kinds of issues with manjaro in the past, on a different PC, and no idea what caused them or how to fix except doing a clean install. Please help me debug this.


It would be nice to start the conversation with:
Hi, Hello, Good morning / Afternoon / Evening!

please post

inxi -Fxxxza

as nice formatted text.

PS: I'm not a Prude, neither Victorian nor Bluenose. :crazy_face:


See also these threads:

It sounds like you need to do some maintenance on your BTRFS partitions (e.g. btrfs balance).


Just found out about the reset configs to default in Garuda assistant. Did that and things seem to have been fixed, as far as I can see. Probably old configs/new packages incompatibilities somewhere. I didn't bother to check them out manually.
I will keep in mind that btrfs balance, and will try that if the lag when writing problem appears.


Interesting - so this may be an issue with KDE rather than the underlying OS... :thinking:


Little guide for people unaware of the Assistant.

Start the Garuda Assistant and press the button, after you have read the warning and acknowledged it.


Ok so this was not a fix. Starting a blockchain syncing program, in addition to downloading a torrent with 3MB/s, causes the huge lags to appear again (it got a lot worse after starting the blockchain syncing).

output of inxi as requested by barna:

Also, sometimes only the Plasma desktop elements are unresponsive, but I can still use firefox without lag, other times it's global, I can only move the mouse and whatever inputs I do during this time will all be processed at the end of the lag period. (it comes and goes). Will try the btrfs balance thing now.

Check /search logs for errors or relevant messages.
journalctl, Xorg etc.

1 Like

You need to search the relevant threads on the forum for these types of issues. There's at least 20 different fixes you might need to implement that have been gone over in great detail already on the forum.

There's no way anyone can predict which fix or combination of fixes will correct things for you. It's your box, the only one who can test out all the potential remedies is you. Sorry, but I don't see any point in rehashing what has been covered many times before in exhaustive detail.

The whole purpose of the forum is to be a permanent reference source for these exact types of issues where you can't write a short concise wiki how to article. No one can perform detailed in depth troubleshooting on your system but you. Sorry, but there's no easy one line fix for this issue, it's all on you to diagnose and correct.


Nice, I ask for help on telegram, they send me to the forums, I ask on forums only to find out I'm on my own. Great.
I'm not knowledgeable about the particularities of this distro (kernel, filesystem, default config and tweaks, etc).
Also not experienced with maintaining and debugging such problems, that's why I asked for help.
Please give me a list of those 20+ fixes I should try tbg.

1 Like

Hi, sorry for inconvenience. It must be some latte dock bug.

We recently received similar requests from multiple users. We are looking into it.

For the time being, restore from earlier snapshot.

1 Like

I think you took the wrong message away from what I wrote. I wasn't blowing you off. There's simply no easy fix in this situation that I'm aware of. If there was an easy fix for this there would be a tutorial on how to accomplish that on the Wiki or the forum. It's simply a case of trial and error working your way through as many suggestions as you can find on the forum.

I'm sorry, but I don't have a comprehensive list of things you could try. It's simply a matter of searching for things you could test from the links @jonathon already posted (and other threads as well).

Sorry, but as far as I know there's no easy fix for symptoms like this as yet. The first place to always start IMO is testing various different kernels to see if that helps.


Lets make something clear.
This is not a HelpDesk, this a forum.

Everyone replying to you is doing so because they decide to spend their free time to help you out.

But now you complain I'm on my own where people clearly wrote and provided the information on what you can try to solve your issue.

Either you have chosen to not read the provided information or just did not see it.
(benefit of the doubt)

Right now it just looks like you expect everyone else to invest their free time to troubleshot your issue, without you investing your own time.

Either you show some own effort or this topic will be another cold case.


I noticed that swappiness after reboot is set to 10, even though in sysctl I set it to 0:
cat /etc/sysctl.conf
vm.swappiness = 0

Any idea why ?

I manually set it to 0 and although the lockups did not disappear completely, it is now a LOT better. I could copy 24GB of a huge file to /home before it froze a bit.



# The swappiness sysctl parameter represents the kernel's preference (or avoidance) of swap space. Swappiness can have a value between 0 and 100, the default value is 60. 
# A low value causes the kernel to avoid swapping, a higher value causes the kernel to try to use swap space. Using a low value on sufficient memory is known to improve responsiveness on many systems.

# The value controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects (VFS cache). 
# Lowering it from the default value of 100 makes the kernel less inclined to reclaim VFS cache (do not set it to 0, this may produce out-of-memory conditions)

# This action will speed up your boot and shutdown, because one less module is loaded. Additionally disabling watchdog timers increases performance and lowers power consumption
# Disable NMI watchdog
kernel.nmi_watchdog = 0

# Enable the sysctl setting kernel.unprivileged_userns_clone to allow normal users to run unprivileged containers.

# To hide any kernel messages from the console
kernel.printk = 3 3 3 3

# The kernel default is to buffer up to 10% of system RAM before flushing writes to the disk, which is insane. By setting a reasonable number of bytes for the `dirty_bytes` parameter, we can avoid sending the system into OOM during a large file transfer.
vm.dirty_bytes = 16777216
vm.dirty_background_bytes = 4194304

###############-NOT USED-#################

# Contains, as a percentage of total available memory that contains free pages and reclaimable
# pages, the number of pages at which a process which is generating disk writes will itself start
# writing out dirty data (Default is 20).
#vm.dirty_ratio = 10

# Contains, as a percentage of total available memory that contains free pages and reclaimable
# pages, the number of pages at which the background kernel flusher threads will start writing out
# dirty data (Default is 10).
#vm.dirty_background_ratio = 5

# This tunable is used to define when dirty data is old enough to be eligible for writeout by the
# kernel flusher threads.  It is expressed in 100'ths of a second.  Data which has been dirty
# in-memory for longer than this interval will be written out next time a flusher thread wakes up
# (Default is 3000).
#vm.dirty_expire_centisecs = 3000

# The kernel flusher threads will periodically wake up and write `old' data out to disk.  This
# tunable expresses the interval between those wakeups, in 100'ths of a second (Default is 500).
#vm.dirty_writeback_centisecs = 1500



Did you ever find out how to fix this, I'm having the exact same problem and it's a gamebreaker for me, it freezes my programs any time any disk activity goes on, whether thats game updates, syncthing backups, extracting or compressing files, nvme ssd, balancing doesn't fix it (it causes it to happen), resetting config doesn't fix it, its a problem straight from a fresh install and I can't stand my games freezing for 30 seconds at a time, or as I type this the browser freezing and catching up

Have you tried disabling btrfs quotas?

Don't necrobump old posts that have obviously been abandoned.

Please read the forum for preexisting solutions related to system freezes and if you can't find a solution after thoroughly searching, then open your own help request. Be sure to read the wiki entry on reporting bugs and post your system inxi on any help request.

Thread locked, no necros, or hijacking please.