Bug 24031 - [855GM] Xorg running very high cpu utilization
Summary: [855GM] Xorg running very high cpu utilization
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) All
: medium normal
Assignee: Carl Worth
QA Contact: Xorg Project Team
URL: https://bugzilla.novell.com/show_bug....
Keywords: NEEDINFO
Depends on:
Reported: 2009-09-18 20:08 UTC by Ted Bullock
Modified: 2010-07-24 04:03 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:

Xorg.0.log (24.09 KB, text/plain)
2009-09-18 20:08 UTC, Ted Bullock
no flags Details
Xorg.0.log with fallbacks debug enabled. (14.37 KB, text/plain)
2009-09-23 13:36 UTC, Ted Bullock
no flags Details

Description Ted Bullock 2009-09-18 20:08:58 UTC
Created attachment 29679 [details]

The process Xorg is running at quite high cpu utilization rates.  On
average betweeen %45 to %75 consistently.

Machine is a Dell 700m with an Intel 855gm graphics chipset.

top reports that the "Xorg" process is the number one cpu hog.

Note: Posted here as prompted at:

Comment 1 Carl Worth 2009-09-22 16:42:27 UTC
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.

Comment 2 Ted Bullock 2009-09-22 20:16:40 UTC
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


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.
Comment 3 Chris Wilson 2009-09-23 09:22:07 UTC
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"
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.)
Comment 4 Ted Bullock 2009-09-23 13:36:55 UTC
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
Comment 5 Eric Anholt 2009-10-09 14:39:02 UTC
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 :)
Comment 6 Stefan Dirsch 2010-04-17 13:59:35 UTC
Ted, is this still an issue with openSUSE 11.3, which already uses the latest
X.Org stack?
Comment 7 Chris Wilson 2010-07-24 04:03:35 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.