Bug 433166 - Plasma slows to a crawl with low CPU usage after certain system setting changes
Summary: Plasma slows to a crawl with low CPU usage after certain system setting changes
Alias: None
Product: kwin
Classification: Plasma
Component: core (show other bugs)
Version: 5.21.0
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
Keywords: efficiency
Depends on:
Reported: 2021-02-18 13:24 UTC by Dan Dascalescu
Modified: 2023-09-06 10:38 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:

some jourrnalctl logs (2.25 KB, text/plain)
2021-02-18 21:48 UTC, twinshadows404
dmesg -T output (110.84 KB, text/plain)
2021-02-18 23:55 UTC, Dan Dascalescu
perf output (253.87 KB, application/x-7z-compressed)
2021-08-30 17:45 UTC, Dan Dascalescu

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Dascalescu 2021-02-18 13:24:12 UTC
I've installed KDE neon 5.21 and have run for the second time in 2 days into this crippling issue. Unfortunately, reproducibility is occasional.

1. Go to System Settings -> Window Management -> Window Behavior
2. Check "Active screen follows mouse"

The OS becomes almost unresponsive. The mouse cursor is responsive, but key presses are buffered and echoed slowly, and switching windows is extremely slow. However, System Monitor reports low CPU usage (under 5%) and is itself the application taking up the most CPU. RAM utilization was under 50% of the 16GB.

The other time I've seen the same behavior was when I switched the Task Switcher to Thumbnails Grid.

KDE Frameworks Version: 5.79.0
Qt Version: 5.15.2
Mesa Intel UHD Graphics 620 on a Core i7 ThinkPad X1C 7th gen connected to external monitor via USB-C
OpenGL 4.6

Logging out and back in did not fix the slowness. I had to reboot.

Please let me know what additional debugging information I can provide when this will happen a 3rd time. Unfortunately I need a stable system so I'll have to revert to a stable version of Plasma after that, unless the bug gets fixed.
Comment 1 twinshadows404 2021-02-18 21:48:35 UTC
Created attachment 135871 [details]
some jourrnalctl logs
Comment 2 twinshadows404 2021-02-18 21:50:05 UTC
I don't think it's necessarily related to that. I've got 100% reproducibility with
1. Open lutris
2. Open Origin

If i click on play in lutris and don't move the mouse the screen with stay on "Connecting to Origin" window. As soon as I move the mouse it starts loading the launcher, but the desktop is very sluggish.

I also noticed that dmesg will print:
perf interrupt took too long

Do you have any of these errors?
Comment 3 Dan Dascalescu 2021-02-18 23:55:47 UTC
Created attachment 135873 [details]
dmesg -T output

I do see "perf: interrupt took too long" in the `dmesg` output, but *after* I rebooted post-crawl. I've attached the `dmesg -T` output up to the timestamp at which I submitted this bug, which was after I rebooted.
Comment 4 Dan Dascalescu 2021-02-19 04:54:32 UTC
Issue has just happened again after changing a few font sizes.

At this point I'm highly reluctant to change any System Settings, due to the high likelihood of having to reboot.

Please let me know if there's a workaround, otherwise I'll have to revert to Plasma 5.18.
Comment 5 Nate Graham 2021-02-19 20:06:32 UTC
"perf: interrupt took too long" is a message that comes from the kernel. Some web searching found a few other examples of people experiencing this same issue in non-Plasma contexts. Seems like your kernel is not happy about something. I think you'll want to submit a bug report at https://bugzilla.kernel.org/. Thanks!
Comment 6 Dan Dascalescu 2021-02-19 20:58:16 UTC
"perf: interrupt took too long" did *not* appear in the `dmesg` output before the ~freeze; only hours after. And the freeze has been triggered only by actions in System Settings that affected the display.

The kernel should be the same as in Kubuntu (where I had not exeprienced this issue on) because I'm running KDE neon 5.21, which claims to be based on the stable Ubuntu 20.04.2 LTS. Its version is 5.4.0-65-generic.
Comment 7 Nate Graham 2021-02-19 21:42:19 UTC
Hmm, maybe that's not related, then.
Comment 8 Dan Dascalescu 2021-02-21 08:23:48 UTC
Happened again when I pressed Alt+F3 to have a window remember its size and position.
Comment 9 Dan Dascalescu 2021-03-07 20:52:15 UTC
Happened again with 5.21.2 when I toggled off the Task Switcher option to Show selected window
Comment 10 Dan Dascalescu 2021-03-13 07:59:33 UTC
Happened again when adding properties to the Special Application settings (tried to make VokoscreenNG remember its size and position, but that just doesn't work - https://github.com/vkohaupt/vokoscreenNG/issues/156)
Comment 11 Dan Dascalescu 2021-04-15 00:05:25 UTC
This bug is fdriving me insane. Now I've created a new Virtual Desktop, and the entire OS slowed to a crawl. Have to reboot again.
Comment 12 David Edmundson 2021-05-10 10:14:41 UTC
Does restarting kwin_x11 fix it?

Whilst it is slow, please run:

perf record --call-graph dwarf -p `pidof kwin_x11`
Comment 14 Dan Dascalescu 2021-08-30 17:45:03 UTC
Created attachment 141162 [details]
perf output

I've run `kwin_x11 --replace` to clear up the ghost window left by #438552. That brought the system to the ridiculous slowness I've described.

I've run that perf command and attached the data file.
Comment 15 Dan Dascalescu 2021-09-17 17:28:05 UTC
Happened again after adding a new virtual desktop. After I clicked Apply - 💥
Comment 16 Dan Dascalescu 2021-09-17 17:29:32 UTC
Running `kwin_x11 --replace` didn't help. Will have to reboot.
Comment 17 David Edmundson 2023-09-06 10:38:41 UTC
This bug was reported against an outdated version of KWin. We have made many changes since the. 
If the issue persists in newer versions can you reopen the bug report updating the version number.