Hello,
thats my first post in the forum so please dont be so hard
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.
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.
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.
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
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.
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.
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.
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
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.