While your solution is a great suggestion, it does not work for this specific problem.
Specifically the current issue is not related to cache/buffer, so it does not do anything. Kwin VRAM usage increases gradually over time even if you are not doing anything and you can track it via btop/htop.
I would say that the turning off swap (even when you are going to turn it on later) in this case is likely to make it worse since you are going to put all the stuff from swap into the already overfilled memory from kwin.
From some debugging that I did, the memory is manually allocated by kwin and never freed, you can check it with pmap which shows them as anonymous regions. Next step is to identify where the leak occurs in kwin and its not that easy as you can’t just attach valgrind to it. You can but you need to rebuild kwin from source without setcap protection to run it with valgrind.
This is the only way that I can fix it as well, except the restart.
Here is a review of the model I have link. And here is the reddit thread that I learned it from.
To my understanding most of the high end laptops are muxed.
Sorry for not replaying I, I tested you solution but it didn’t work for me the RAM was still in the same state and not freed even after running the script manually.
What happened on each step:
There is no option for me to disable the neither of the graphics cards in the BIOS menu, but i did all the other things in this point. The laptop was running normally for 3-4 hours when I decided to plug in the external monitor (HDMI → HDMI directly to the laptop). It was operating normally until the same thing happened the ram was still eaten away by kwin_wayland. Tested the same way with the dock with the same results.
No problem when running the both nvidia proprietary drivers and the nouveau open source ones withouth the external monitor. When I connect the external monitor no matter through the dock or not the RAM eating repeats itself.
Same issue persists.
Not possible to disable neither of the GPUs in the BIOS.
That’s right, all fairly current models, even mid-end ones, are muxed. That’s so normal these days that most manufacturers don’t mention it anymore. Little bit more info:
Your ASUS TUF Gaming A15 FA506QR is definitely an optimus laptop, and Asus is known for being able to activate/deactivate the dGPU/iGPU in the BIOS. No idea why it doesn’t work for you.
It’s stupid, of course, because you can’t narrow it down to the lowest level.
So it always happens no matter which drivers are installed and no matter which GPU is actively used, do I understand that correctly?
Yes you do understand correctly, it doesn’t matter which driver is installed or which GPU is active the moment i connect any external monitor this issue arises.
Thanks for the link/soruces. I actually find that more recent laptops tend to have this option where the USB-C are routed to different GPU output which is neat.
I had a look into these and it seems there are people that have reported the same problem. I noticed someone saying that this problem happens to them after NVIDIA driver 555.77 (Source). Could you (@wh1t3_r4v3n) try to revert back to earlier version ( 565.57 from Arch repos ) and see if the problem presists?
I personally did not encounter this problem when using only the integrated AMD GPU… Sadly I cannot test with only the NVIDIA GPU active as I don’t have this option available for my laptop: its either iGPU only or iGPU + dGPU.
I switched to X for now. Downgrading did not work for me either. I am also getting better performance on Xorg than on Wayland with the latest Nvidia drivers.
I tried that, but there was no effect, didn’t do anything for me.
I guess I will do the same, at this point in time I give up. When I want to game I will just switch to Wayland for the better performance.
Thank you all for the help and all the suggestions and solutions that you offered. I greatly appreciate them. Special thanks to @nepti@tbg and @totoshija for taking the time and trying to help me.
P.s
I still haven’t gotten my self involved into the kde buglilst but i will next week
