Hi Ted,

Thanks for your bug report.

Can you tell us more about what's running when the CPU utilization of the Xorg
process is high? Xorg only does work on behalf of clients, so high utilization
of the CPU by Xorg could be any of the following:

* A buggy application requesting excessive redraws, (things like browser
  plugins for animated flash ads seem to do this kind of thing frequently
  for example).

* A well-behaving application triggering bugs in the X driver, (such as the
  driver falling back to software where it doesn't need to)

* A well-behaving application and driver just running into hardware limitations.
  (Perhaps the application is asking for something that simply does need to
  be computed on the CPU.)

Anyway, if you can provide more details on what's actually happening, then we
could perhaps tell you how to investigate further to determine which of the
above might be happening.

And if you could remove the NEEDINDO keyword from this bug report when you
reply, that would be helpful.

-Carl

Hi Carl,

So here is what is happening.  Doing any number of normal things on the desktop raises the CPU usage of X.org significantly.  For instance there is a distinct increase just from moving the mouse from window to window (say from nautilus to gedit).  Moving a window is another significant contributor as well.

The redraw time is also distinctly noticeable as well.  For instance, if I move a window it takes a significant fraction of a second for the window contents to redraw.

Other marked contributors to X.Org cpu usage spiking are:

* Scrolling
* Maximizing
* Minimizing

etc

Glade 3 is completely unusable in this current state

Also, there are some websites that bring firefox to a near standstill.  For instance, scrolling on planet.gnome.org is completely immposible, and I have started to use a feed reader just to be able to access the content.

Surprisingly, sites with flash on them are not "that" bad in comparison to the problems I have been encountering.

Lastly I should mention that this happens both "with" and "without" the metacity compositor enabled.  Interestingly the desktop appears smoother with the compositor enable.

We have very recently fixed a number of bugs on i8xx class hardware that reportedly affected firefox, either causing hangs or triggering slow software fallbacks. Carl has (or will very shortly) release a new RC for Q3 which will contain these fixes and it would be useful to check if that catches all the issues that are afflicting you.

Slow, high cpu usage, rendering is invariably caused by triggering software fallback. During such a spike it would be useful to know which particular paths are active (so we can identify the fallback and hopefully the cause). To gather such information the easiest tool would be sysprof (or perf, or oprofile etc). Also you can enable
  Section "Device"
    Option "FallbackDebug" "True"
  EndSection
which will emit a debug statement to Xorg.log everytime we hit a fallback path. (Though such information tends to be voluminous and suffers from poor signal-to-noise.)

Created attachment 29815 [details]
Xorg.0.log with fallbacks debug enabled.

Ok, I am attaching a log from running with fallbacks debug on.

It was not a very long test as these things go, I just opened firefox, browsed to planet gnome, closed firefox, open the terminal and killed X.

If necessary I do other such tests for other common things that I have noticed spikes on

That log doesn't appear to have fallback debugging enabled.  I don't think it would be terribly useful, though, as we need to know when exactly in the log you were seeing slowness.  I find sysprof to be a much more useful tool for debugging this -- when the CPU is busy and you don't think it should be, run it for 10 seconds or so, and upload the resulting sysprof data here.

And don't forget to clear NEEDINFO when you do :)

Ted, is this still an issue with openSUSE 11.3, which already uses the latest
X.Org stack?

Timeout. I assume it was one of the unnecessary fallbacks that have since been fixed. If you do find some instances were Xorg is spending excess amounts of CPU time, perf is your friend -- and please do submit profiles.