Introduction

Symptoms:

According to top or other process load tools, X is using 100% (or higher) CPU for a period of time.
X is consistently using CPU higher than normal (where normal is 1-10% typically).

Non-Symptoms:

The high X load only lasts a few seconds. This is typically correct behavior.
High memory load rather than CPU load. This is a different issue.

It is important to note that X having high CPU load is the symptom, and may not itself be the root cause.

Things to include in a bug report

What is the idle CPU usage of X after immediately logging in and not opening any applications?
What specific steps cause high CPU usage of X?
How long specifically does the high CPU usage of X last once encountered?
If immediately after the high CPU usage of X occurs, you only kill processes that are not xorg, which do you have to kill specifically for the CPU usage to return to normal?
Once the reproduction steps are narrowed down, attach an uncompressed, and untarred output of running xserver under gdb, and separately, strace. This will help identify if the xserver is stuck in a loop, and further root cause.

Why is there high CPU usage associated with X?

Here are a few potential causes of why top reports high CPU usage associated with X:

Problem: Client Applications or Client-side Services

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 saw 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 so frequently (there are cheaper X calls they can use).

vino-server

Sometimes, after somebody connects or just at random, vino-server seems to go wild and pushes X Server CPU load to 80%+. Graphics will feel kind of slow. To test if this is the case, execute the following command:

  $ killall vino-server

If X CPU usage drops to about 10% or less then you found the problem. To work around the issue type "vino" into the Dash search box and select "Desktop Sharing". Then uncheck "Allow other users to view your desktop" in the window opened. vino-server will not be started anymore.

Problem: High CPU Due to 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. This is normal - you're using the CPU to make up for the lack of GPU.

Problem: GPU Lockup

On occasion the GPU will lockup, and this will cause the CPU to exhibit a high load. This is quite rare but has been known to happen. Look at the end of /var/log/Xorg.0.log to see if any error messages are printed there. "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 "GPU lockup" bug rather than "high cpu" - high cpu is just a side effect in this case.

Other X Server Bug

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.