| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 43 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 96:17:09 |
| Calls: | 290 |
| Files: | 904 |
| Messages: | 76,426 |
Greetings,
Has anyone else seen grossly excessive CPU load since adopting the new Wayland way of doing things? /Top/ is showing 1300% going on kwin_wayland
and the whole of the rest going on plasmashell.
I need hardly say this doesn't make a responsive system.
On Thursday 5 September 2024 07:32:21 BST Peter Humphrey wrote:
Greetings,
Has anyone else seen grossly excessive CPU load since adopting the new Wayland way of doing things? /Top/ is showing 1300% going on kwin_wayland and the whole of the rest going on plasmashell.
Ouch! No, this is definitely excessive. This is what I have here on a Wayland Plasma desktop, with gkrellm, kmail, a text editor and a couple of terminals running:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4257 michael -2 0 4812308 226288 156940 S 0.7 0.3 0:06.62 kwin_wayland
4640 michael 20 0 193240 30508 24576 S 0.7 0.0 0:02.58 gkrellm
I need hardly say this doesn't make a responsive system.
Quite so. Dare I ask if you're observing this on a system running NVidia graphics?
... Perhaps I should start recompiling things...
Has anyone else seen grossly excessive CPU load since adopting the new Wayland way of doing things? /Top/ is showing 1300% going on kwin_wayland
and the whole of the rest going on plasmashell.
On Thursday 5 September 2024 07:32:21 BST I wrote:
Has anyone else seen grossly excessive CPU load since adopting the new Wayland way of doing things? /Top/ is showing 1300% going on kwin_wayland and the whole of the rest going on plasmashell.
Another thing: the plasma system is not preserving my desktops between sessions. Well, firefox and 3 x gkrellm all reappear, but on the first desktop, not where I put them. 3 x konsole, dolphin, kmail, korganiser:
none of these restart.
On Thursday 5 September 2024 13:47:29 BST I wrote:
... Perhaps I should start recompiling things...
After an emerge -e1 kwayland plasma-workspace and a reboot, kwin_wayland is down to 20-60% CPU and plasma_shell is barely visible in /top/.
Much improved, but it still isn't right.
On Thursday 5 September 2024 15:43:00 BST Iwrote:
On Thursday 5 September 2024 13:47:29 BST I wrote:
... Perhaps I should start recompiling things...
After an emerge -e1 kwayland plasma-workspace and a reboot, kwin_wayland
is
down to 20-60% CPU and plasma_shell is barely visible in /top/.
Much improved, but it still isn't right.
It came back again, so I ran a complete -e, rebooted, recompiled the kernel again and rebooted again.
It's all back as it was - no CPU cycles left for anything else but wayland and plasam-shell.
How to debug this?
At a simple level you can check this file for any obvious problem:
~/.local/share/sddm/wayland-session.log
Your symptom could be related to software rendering used by the kwin compositor, as opposed to OpenGL. Mesa with appropriate USE flags should provide what your graphics need. Have a look in kinfocenter, or run:
qdbus6 org.kde.KWin /KWin supportInformation
and check the section under Compositor, Compositor Type is not showing Xrender or software rendering.
Beyond this I think you're into compiling stuff with debugging symbols and trying to understand where code fails:
https://community.kde.org/KWin/Debugging
I think I know what it is: the kernel's list of firmware blobs is empty. I don't know where they all went, but it shouldn't be too hard to find them.
On Friday 6 September 2024 01:33:04 BST Peter Humphrey wrote:
On Friday 6 September 2024 00:21:31 BST Peter Humphrey wrote:
I think I know what it is: the kernel's list of firmware blobs is empty. I
don't know where they all went, but it shouldn't be too hard to find them.
Indeed it was so. Now fixed and working fine.
Without all requisite firmware for your graphics the Kwin compositor will fall back to software rendering. As you've experienced without hardware acceleration Kwin will eat up CPU cycles.
Emerging sys-kernel/linux-firmware and configuring your system to use it fixes the problem by providing the necessary code for the graphics card to
do the heavy lifting:
On Friday 6 September 2024 00:21:31 BST Peter Humphrey wrote:
I think I know what it is: the kernel's list of firmware blobs is empty. I don't know where they all went, but it shouldn't be too hard to find them.
Indeed it was so. Now fixed and working fine.
On Friday 6 September 2024 10:10:47 BST Michael wrote:
On Friday 6 September 2024 01:33:04 BST Peter Humphrey wrote:
On Friday 6 September 2024 00:21:31 BST Peter Humphrey wrote:
I think I know what it is: the kernel's list of firmware blobs is empty.
I
don't know where they all went, but it shouldn't be too hard to find them.
Indeed it was so. Now fixed and working fine.
Without all requisite firmware for your graphics the Kwin compositor will fall back to software rendering. As you've experienced without hardware acceleration Kwin will eat up CPU cycles.
Emerging sys-kernel/linux-firmware and configuring your system to use it fixes the problem by providing the necessary code for the graphics card to
do the heavy lifting:Yes, I know, and I had it set up from when I acquired the machine. The mystery is why it was missing from my two most recent kernels.
You could have inadvertently cleaned this package from your
/var/lib/portage/ world, or unmerged it for some reason.
Worth noting, dmesg would have complained it can't find this & that firmware.
Either way, problem solved. :-)