[SOLVED] Possible memory leak in kwin

[Tanker Bob]

I upgraded this morning and everything went smoothly. However, I noticed that 20.04's memory usage increases gradually over 10-15 minutes, then one the the 12 CPU threads hits 100% for a couple of seconds while the system freezes, then the memory use drops to normal and normal operations commence. Using KSysGuard, I found that kwin_x11 seems to be the culprit. It accumulates upwards of 8 MB of shared memory before shedding back to about 200K, then starts again. I'm using an NVidia GeForce GTX 1050i with the 440.64 driver. Anybody else seeing something this?

[claydoh]

I don't think 8mb is a leak. Kwin is your window manager. Mine has been sitting here for the past 10+ mins @ 36.6Mb/92mb shared. Will check a fresh session, and see any difference, but yours look quite good really. Other than the cpu spike that is.

Using top, or htop will probably give you more detailed info than Ksysguard, probably too much.
Each different monitor can report things using different methods,so they may not always line up with each other.

[Tanker Bob]

I don't think 8mb is a leak. Kwin is your window manager. Mine has been sitting here for the past 10+ mins @ 36.6Mb/92mb shared. Will check a fresh session, and see any difference, but yours look quite good really. Other than the cpu spike that is.

Using top, or htop will probably give you more detailed info than Ksysguard, probably too much.
Each different monitor can report things using different methods,so they may not always line up with each other.

Thanks! I'll give that a run. I monitored 19.10 for a while for other reasons and never observed that behavior. Memory use stayed pretty steady other than the other issue I was working. I'm thinking that the CPU spike may be related to the screen tearing issue with kernel 5.4 and NVidia drivers.

[claydoh]

My kwiin_x11 is about the same after rebooting, higher than yours still.
But I am using the same plasma version, but on neon, so using the 5.3 kernel. Probably not a factor om ram usage.
I switched to AMD some time ago due to silliness and semi constant tweaking Nvidia provides as a user experience feature with every driver or kernel update

[Tanker Bob]

My kwiin_x11 is about the same after rebooting, higher than yours still.
But I am using the same plasma version, but on neon, so using the 5.3 kernel. Probably not a factor om ram usage.
I switched to AMD some time ago due to silliness and semi constant tweaking Nvidia provides as a user experience feature with every driver or kernel update

I hear ya. I've stuck with NVidia because they always support Linux in my experience, though as you say, the user experience has varied around kernel changes. Like now, for instance. Haven't tried AMD. I'm not familiar with their model line.

[Tanker Bob]

My kwiin_x11 is about the same after rebooting, higher than yours still.
But I am using the same plasma version, but on neon, so using the 5.3 kernel. Probably not a factor om ram usage.
I switched to AMD some time ago due to silliness and semi constant tweaking Nvidia provides as a user experience feature with every driver or kernel update

I hear ya. I've stuck with NVidia because they always support Linux in my experience, though as you say, the user experience has varied around kernel changes. Like now, for instance. Haven't tried AMD. I'm not familiar with their model line. What's in your machine?

[claydoh]

I have a used XFX AMD Radeon RX 480 in a refurb HP Pavilion 590 i5-8400 desktop.
AMD support Linux FAR better than Nvidia, imo
No third party non-free drivers to install, though updated Mesa/Vukan/etc via PPAs do make some difference in performance. AMD supports the free drivers, and even recommends them. The AMDGPU-PRO is more for professional workstation use, and is actually based on the open source driver.
But zero tearing, glitches, or other anomalies for the past few years using two AMD cards (previous is an RX560 in a low profile SFF HP desktop). No tweaks to settings etc, though i am sure there that is possible.

Plays Metro Exodus at 1080p at ~75-90 fps on iirc high settings somehow.

[Tanker Bob]

Thanks! I'll look into those. I installed an NVidia GeForce GTX 1050 Ti when I built this desktop a couple of years ago. It worked perfectly until I upgraded to 20.04 today. My Net search turned up a lot of issues between the 5.4 Linux kernel and the current NVidia driver relative to the vertical sync.

So, I took a drastic approach to fixing my display problems. I installed Linux kernel 5.6 from the Ubuntu kernel page per the instructions at http://ubuntuhandbook.org/index.php/...tu-linux-mint/. Worked like a charm, and both the NVidia driver and VBox work fine. Looks like the problem was indeed between the NVidia driver and the 5.4 kernel, which was supposedly fixed with the 5.5 kernel. I don't normally stick my neck out by changing kernels, but it worked out this time.

[Tanker Bob]

After the 5.4.0-29 Kubuntu kernel update came out yesterday, I retested it. That update seems to fix the NVidia display issues, including the kwin_x11 symptoms that I saw earlier. So, I'm back to using the stock kernel since the 5.6.7 kernel isn't supported and there's nothing in the newest kernel that I need right now. I kept it as a boot option, though, just in case.

[Tanker Bob]

After the 5.4.0-29 Kubuntu kernel update came out yesterday, I retested it. That update seems to fix the NVidia display issues, including the kwin_x11 symptoms that I saw earlier. So, I'm back to using the stock kernel since the 5.6.7 kernel isn't supported and there's nothing in the newest kernel that I need right now. I kept it as a boot option, though, just in case.

I lied. The video is better, but not fixed. Closing and then reopening a window causes kwin_x11 to shed the extra memory, causing the screen to freeze for a few seconds. It seems to be much worse in Zoom with several participants. Looks like it's back to 5.6.7 for now.

[Tanker Bob]

I lied. The video is better, but not fixed. Closing and then reopening a window causes kwin_x11 to shed the extra memory, causing the screen to freeze for a few seconds. It seems to be much worse in Zoom with several participants. Looks like it's back to 5.6.7 for now.

Figured it out. It's video that cause the memory leak. With the stock 5.4 kernels, playing any video causes kwin_x11 to continuously use more memory until the RAM literally runs out. Playing multiple video streams hastens that process dramatically. Zoom with 5 participants will eat up 14GB in about 5 minutes. Same with VLC with multiple instances running. Closing the instances recovers the memory.

When I boot with 5.6.7, the memory stays constant even with 5 or more videos running simultaneously. the kwin_x11 memory drops slightly as each video stops. No memory leak.

There's definitely an issue with NVidia driver 440 and the 5.4 kernel, even the updated kernel from yesterday. The difference is that the initial stock kernel for 20.04 contributed to leaked memory and screen tearing all the time. The updated 20.04 kernel released yesterday only appears to leak when playing videos. The 5.6.7 kernel appears to resolve all these issues with the same 440 video driver version. I'll file a detailed bug report tomorrow.

[claydoh]

Have you considered trying a different driver version?

[Tanker Bob]

Have you considered trying a different driver version?

Yes, but others have done so without success. As far as I can find on the web, the only fix is to update to kernel 5.5 on up. There was apparently a change made in the 5.4 kernel that resulted in this issue, because it doesn't happen in 5.3.x or 5.5+. My concern now is that I won't be able to go to Neon unless whatever fix is in 5.5 is ported to 5.4. There's still a few months for that to happen. I read all the change logs last night for 5.4.29 on up and don't see any mention of a related fix. I updated to 5.6.11 this morning, but I have to stop checking the mainline kernel page every day or there'll be no end to updating...

Update on 5/6/20: The kwin_x11 vs. 440.64 driver memory issue returned in mainline kernel 5.6.11, though not as bad. Testing indicates that 5.6.7 through 5.6.10 work fine. That should help narrow down the issue. Also, I found that the issue doesn't happen in NVidia's PRIME On Demand mode, only in the Performance mode. The On Demand mode produces some strange screen relics and performance anomalies, though, so that's not an option. For now, I'm running the 5.6.10 mainline kernel, and probably for the foreseeable future. I don't want to make a career of this. I'll submit bug reports to both the Ubuntu kernel group and NVidia later today.

[Tanker Bob]

After a lot more time and work, I found that the problem is the way that the NVidia driver using PRIME works with Xserver. Or rather, doesn't work with it. After multiple attempts at editing conf files, changing settings, and other stuff, I finally reverted to the nouveau driver. The open source driver works fine and performance is adequate. Problem truly solved now, although I cannot help but feel that I'm wasting most of my video card's capability.