GNOME Bugzilla – Bug 762513
wayland: mutter high CPU usage when idle
Last modified: 2016-03-24 13:17:57 UTC
Created attachment 321926 [details] strace -Ttt -s4096 -p $(pidof gnome-shell) -o gnome-shell-strace.log Description Running gnome-shell/mutter as Wayland compositor uses 20%/25% of CPU even when idle, without any window on screen and not even moving the pointer. Additional data: This is on a Lenovo x61 with an Intel GM965/GL960 integrated graphics controller. Attaching strace and top outputs.
Created attachment 321927 [details] top -b -d 0.5 -n 20 -p $(pidof gnome-shell) |& tee gnome-shell-top.log
Note, this is on Fedora rawhide: gtk3-3.19.9-1.fc24.x86_64 gnome-shell-3.19.90-1.fc24.x86_64 mutter-3.19.90-1.fc24.x86_64
I've seen this as well. It only seems to happens after running gnome-shell for a while. When you posted this bug, my shell was idling around 20-30% so I attached to using gdb -p via another and could see that it repainted continuously even when I was on an empty workspace without moving the pointer. Before having tracked down what the source of the continuous repaint was originating from gdb froze and gnome-shell crashed, generating a backtraceless core dump. Now it's back on ~0% idle when doing nothing. I'll debug again when it happens next time.
Oh you're right, now it calmed down again... I should also mention that I filed this bug after trying to reproduce bug 762468 so maybe it's related.
I hit this again and managed to debug some. What I can see is that, if I add a break point on _clutter_stage_window_schedule_update(), I will hit this continuously when I'm on an empty workspace with no windows and not moving the mouse cursor. This scheduling request seems to always come from a gtk_container_idle_sizer callback. This callback is invoked on the layout GDK frame clock phase, and will reschedule the layout phase until it detects that itself has been allocated. The problem is though that the widget never seems to gets allocated. I have yet to find out why. What I know so far is that the GtkContainer is actually a ShellEmbeddedWindow, which overrides the check_resize vfunc of the GtkContainerClass where it queues a clutter relayout. The ShellEmbeddedWindow's associated ShellGtkEmbed is a ShellTrayIcon. The ShellTrayIcon is, at least in this case now a Seapplet tray icon (SELinux). When I clicked the tray icon and opened the SELinux alert, the trayicon disappeared, and gnome-shell stopped taking ~20% CPU. There are two other tray icons that doesn't cause this behavior.
I got the alert again (I get often because some Firefox plugin tries to "execute" my jhbuild libgdk instead of the one in /usr). The way to reproduce it is: 1. Do something causing a SELinux alert that would end up with a the tray icon 2. "touch" bottom left tray icon container thing. No need to make it open, just pass by it with the pointer. Mutter will now take ~30% of the CPU by repeatedly failing to allocate the tray icon embedded window actor. The work around to make it stop is to first open the tray icon container, then close it again by pressing the [ < ] button. At that point, the realloction scheduling stops until the tray icon container is either "touched" or opened again.
I believe my GTK patch in bug 763650 fixes this.
(In reply to Cosimo Cecchi from comment #7) > I believe my GTK patch in bug 763650 fixes this. Yes, I think so as well as I don't see any gnome-shell unexpected or abnormal CPU usage anymore and I can'r reproduce with the tray icon either.
Closing as a dupe of 763650 as I cannot reproduce anymore. *** This bug has been marked as a duplicate of bug 763650 ***