Lagging KDE Desktop on supposedly hdd/ssd intensive tasks like unrar files or simple copying

thats my first post in the forum so please dont be so hard :upside_down_face:
I probably most likely need help to find a problem causing parts of the desktop gui to hang on supposedly hdd/ssd intensive tasks like unrar files or simple copying.
Mousemovement is still working but clicks have no direct effect for a few moments and appeared to be written to some kind of buffer.
Im not sure if theres a relation between hdd/ssd intensive tasks and the lagging ui but if i do so i certainly get the lags.
Can you please give some hints finding the cause.

Thanks for help

Welcome to the forum!

The fact is that I/O is a high-privilege and high-priority process, and it’s mostly atomic — i.e. uninterruptible. That’s why processes that heavily rely on I/O can appear to hog up the CPU and seemingly bring the desktop to a halt. Everything still works, though — so it only appears frozen — but the system will need its time to complete the task.

An additional factor in this regard is the amount of RAM you have in your machine, and whether you have configured a swap device or not. If the machine doesn’t have loads and loads of RAM, then it’ll start swapping, and that too is an I/O operation, so then things can really become unusable.

But the wrong thing to do would be to reach for that reset/power button. Just let things take their time and everything will return to normal eventually. :slight_smile:

Now, there are a couple of things that could help mitigate this sort of lag to a certain extent, but both of them are not exactly for everyone. The first one is to use the nice and/or renice commands, but then you need to know what you’re doing.

The second one is not something one can do, but it’s a hardware-based thing. You may have already heard of SCSI. Without getting into the details, SCSI devices have their own drive controller and don’t have to rely on the CPU as much, which allows them to have a much higher data throughput without hampering the user experience. But SCSI is expensive and commonly not found in the typical consumer-grade market — it’s more of an enterprise-grade thing.

But so anyway, yeah, I/O can indeed bog down your computer. :man_shrugging:

Thanks for the extensive reply :slight_smile:

I have to agree that it only appears froze because audio is still working while parts of the gui lag.

The amount of used ram stagnates at 5 gigs (still 11 available). At the moment im using a swap but i already tried without swap but that seems to be not the cause of the lags.

The lagging phase is only about a few seconds but always reccuring until the hdd/ssd intensive task is finished.

I will look into it but i also dont believe that will help me…

What does seem strange is that a previous manjaro installation with xfce and the exact same hardware dont have this problem :disappointed_relieved:

In that case, I would suspect that it may be a kernel issue — either a kernel configuration issue, or a change in the inner workings of the kernel with regard to process management.

You could always switch to one of the LTS kernels — the most recent one is 5.15, but I myself am still using 5.4, and that’s a rock-solid stable one.

Thanks i will try that! :metal:t2:

Booted into Kernel 5.15 and 5.4 and unpacked some stuff with unrar.
Neither of them helped :disappointed_relieved:

Maybe the problem is with unraritself. I’ve never used it, so I can’t tell.

As I said, the problem also occurs when copying with dolphin or cp in shell.
It looks like the problem is only present when writing to the luks encrypted root filesystem. If im writing to another internal sdd (ntfs encrypted with bitlocker) then there is no temporary freezing/lagging of the desktop gui happening.

You didn’t mention LUKS in your original post. Of course writing to a LUKS container is going to be CPU-intensive and atomic. :man_shrugging:

Sorry that was absolutely my mistake to forget about that fact. But the temprorary freezes are certainly not a normal behaviour. Cpu is Ryzen 5 3600x who should handle this easily or am i wrong?

It depends on how large that file is that you’re decompressing. As I said, I/O is atomic, and you’re reading and decompressing a file on an encrypted filesystem.

The process itself is uninterruptible beyond the kernel’s preemption points, and no matter how high the clock speed or how many cores/threads your CPU has, it’s going to get the hiccups at some point — they’re not freezes, they’re stalls.

I even get that with timeshift sometimes on a 6-core Intel i5 when it finalizes the backup to a secondary drive, because that’s the moment where it flushes the buffer to the physical device before unmounting the filesystem with the backups.

Writing to the virtual filesystem layer in memory will usually be without hiccups, but it’s the physical write to the device that cannot be interrupted, and the same is true for disk reads from an encrypted filesystem.

It is absolutely true that it only happens with files that are several gigabytes in size.
But there is nothing I can do about it?
The constant recurring lags make browsing with firefox or chrome almost impossible without freaking out. :face_with_spiral_eyes:
When music is playing on spotify or youtube it is strangely not interrupted.
Is there perhaps a way to improve the behavior via settings?
It is also funny that I have never read from other people about this problem or find nothing about it :man_shrugging:

Many thanks for the help :slightly_smiling_face:

I’m not sure. If there is, then it would be done by tweaking kernel parameters, but that’s not for the faint of heart. To be honest, even I won’t mess with that, and I’ve got 23+ years of experience with GNU/Linux, including configuring and compiling kernels.

Ok that sounds very unpleasant :cry:
I had hoped that a “simple” solution could still be found…
Many thanks for your help!

I did not give up and found a solution :partying_face:

No more hangs and the performance of unrar is also better and faster with luks encrypted ssd :smile:

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.