Hi - X is taking up a larger amount of CPU than normal. It usually sits around 50% (as seen in top), and will sometimes cap out at 100%. When it does so, keyboard repeats are slow (and maybe other things). Once I alt-tab, the utilization goes back to 50% or so and the keyboard repeats are fine. perf top suggests the hotspot is nvidia_drv.so at 0x86e4a and nearby locations: 21.78% nvidia_drv.so [.] 0x0000000000086e4a 6.11% nvidia_drv.so [.] 0x000000000008af5c 4.70% nvidia_drv.so [.] 0x0000000000086e56 It looks like a busywait (down below. extra ASM for context): 86e30: 48 85 f6 test %rsi,%rsi 86e33: 74 28 je 86e5d <nvidiaAddDrawableHandler@@Base+0xbf0d> 86e35: 48 8b 46 08 mov 0x8(%rsi),%rax 86e39: 48 85 c0 test %rax,%rax 86e3c: 74 1d je 86e5b <nvidiaAddDrawableHandler@@Base+0xbf0b> 86e3e: 80 78 20 00 cmpb $0x0,0x20(%rax) 86e42: 75 0e jne 86e52 <nvidiaAddDrawableHandler@@Base+0xbf02> 86e44: eb 1c jmp 86e62 <nvidiaAddDrawableHandler@@Base+0xbf12> hot loop: 86e46: 80 78 20 00 cmpb $0x0,0x20(%rax) 86e4a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) 86e50: 74 09 je 86e5b <nvidiaAddDrawableHandler@@Base+0xbf0b> 86e52: 48 8b 40 08 mov 0x8(%rax),%rax 86e56: 48 85 c0 test %rax,%rax 86e59: 75 eb jne 86e46 <nvidiaAddDrawableHandler@@Base+0xbef6> 86e5b: f3 c3 repz retq 86e5d: 48 8b 07 mov (%rdi),%rax 86e60: eb d7 jmp 86e39 <nvidiaAddDrawableHandler@@Base+0xbee9> 86e62: f3 c3 repz retq That .so is /usr/lib64/xorg/modules/drivers/nvidia_drv.so, part of nvidia-drivers-384.90.
I still have this bug with the latest nvidia-drivers (387.22), and I'd like to help fix it. What's the usual way to solve these sorts of bugs? Is there a common point of contact with nvidia that I can talk to or something?
I created a thread on nvidia's board and will update here if/when it gets resolved: https://devtalk.nvidia.com/default/topic/1026154/linux/xorg-nvidia-module-cpu-utilization-is-high/
Turns out the culprit is xfce4-panel. Looks like it's polling something or other.
Hi - The culprit applet is Window Buttons. I removed it and the CPU utilization problems went away. That makes sense, somewhat, in that the problem temporarily goes away when I alt-tab (switching the active program). Possibly a red herring, but when I add the Window Buttons applet, I get this error (running xfce4-panel from a terminal): (xfce4-panel:30986): Gtk-WARNING **: Allocating size to panel-tasklist-arrow 0xcd3960 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? When the applet is running, xfce4-panel appears to communicate a lot more with the X server. Specifically, if I strace xfce4-panel, it is usually idle. If I mouse-over the panel, I'll get small number of these: poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) writev(3, [{iov_base="5 \4\0\2:\33\1\0:\33\1\306\0\26\0\212\4\6\0\3:\33\1\2:\33\1(\1\0\0"..., iov_len=16360}, {iov_base=NULL, iov_len=0}, {iov_base="", iov_len=0}], 3) = 16360 recvmsg(3, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable) FD 3 is a socket, connecting to /tmp/.X11-unix/X0 (confirmed via strace). When I run the Window Buttons applet, I get a constant spew of those connections to the X server. I tried toggling a few options for Window Buttons, but for now I just have to remove the applet.
I played with this a little, and if I "Lock Panel" (right click on the lower panel which has the Windows Buttons applet), then the utilization problem goes away. For some reason, Lock Panel is only an option when I right click on the lower panel, but not if I get to the Panel options from the upper bar. Anyway, I can live with this, though I think there's still a bug somewhere.
What GTK+3 theme are you using? If it's one of xfce themes, please try a different one. They have known bugs like this.
