HighCPU
On occasion top might report high CPU usage associated with X. We get numerous bug reports about this. There are a number of causes:
Client Applications
In general, most CPU loads are driven by client applications overtaxing the server. Thus, in a way the X load is the sum of client application loads. For instance, the program might be making resource-intensive xlib calls in a tight loop. In almost all such cases, closing the offending program will cause the X load to go back to normal.
The normal troubleshooting progress is to boot fresh, do whatever is needed to reproduce the high CPU loads, and then start killing processes one by one until the CPU load resolves.
An example we've seen (bug 307306) is where a daemon process does polling on X calls, such as to watch for if a monitor is present. These xrandr calls can be expensive because they do a probe and analysis of the monitor's firmware. So as a result the daemon drives X's CPU utilization through the roof (and causes a bunch of EDID stuff to fill up the Xorg.0.log). The solution in these cases is to make the daemon stop doing the expensive polling (there are cheaper X calls they can use).
Other examples we've seen of client apps driving up X load include:
- KDE services
- gnome-power-manager
- gnome-settings-daemon
- rendering engines for firefox or other applications
- video players
- compiz effects
- kwin effects
- certain windowing system themes (esp. ones with blending, animation, etc. effects)
Software Rasterizing
Most modern graphics hardware has the ability to perform graphics calculations such as image rasterizing. In theory, X's graphics drivers would rely on the hardware when it needs to do these kinds of calculations, but this is not always the case. When it does them in software rather than hardware, you will see higher CPU loads in X. Check for this via glxinfo:
$ glxinfo | grep render direct rendering: Yes OpenGL renderer string: Software Rasterizer
High CPU loads will be noted under this condition especially when moving windows, scrolling in firefox, and when compiz is enabled.
X Server Lockup
The X server itself can get stuck spinning in a loop, which will usually exhibit symptoms including high (>100%) CPU loads. First look at the end of /var/log/Xorg.0.log to see if any error messages are printed there. /var/log/gdm/* is another place to look for error messages. "Stuck in an infinite loop" messages are a good sign your xserver has locked up; in this case it's definitely an X bug, but be sure to file it as a "xserver lockup" bug rather than "high cpu" - high cpu is just a side effect in this case.
If none are seen, try exiting the X session; sometimes if X is in a busted state the shutdown routines will complain about it. After restart look at /var/log/Xorg.0.log.old and /var/log/gdm/*.
Other X Server Bug
In a normal, quiescent desktop system, X will require less than 10% of the CPU load. If you've ruled out the involvement of a client application and other causes listed above, the next step is to figure out what X is actually doing during these high load situations.
One approach is to attach to it in gdb (see X/Backtracing for directions) and take several backtrace snapshots at various points in time. Compare the function listing. You may see one function midway up the stack that appears consistently in all the backtraces; that can indicate that X is stuck in that particular function call. Setting a break on that function and stepping through it can provide some additional context as to what X is trying to do.