[i965] Kubuntu: High %CPU/Power Usage unless downgrade to 2.4 (UXA/EXA)

[Richard Guo]

Binary package hint: xserver-xorg-video-intel

This issue is a regression from Hardy. I did a clean install of Kubuntu Jaunty RC, using ext4 for partitions. Then I disabled composite effects via xorg.conf and KDE4 settings. The first thing I noticed was that the laptop (Lenovo T61 with Intel GM965 card) was *noticeably* warmer than before, to the point where I can't use it on my lap anymore.

I did some measurements using powertop and top to find the guilty process.

Top showed the process Xorg taking up 20% of CPU just to redraw the top output. Nothing was open except the konsole window where the testing was done. This is in comparison with 1-2% CPU usage on idle for Hardy.

Powertop showed fewer causes for wakeup than before (~100 vs ~180 with KDE3 on Hardy), but the CPU spent more time in higher P-states (14% vs 1%). This is consistent with the Xorg process usage that top showed. Absolute power consumption under battery operation. In hardy (sorry, I don't have the output of powertop on hardy), the power use was 12 W with wireless on, idle, and the dimmest screen brightness. In Jaunty, I'm seeing consumption in excess of 15W under the same conditions.

The line "58.5% ( 98.2) <interrupt> : i915@pci:0000:00:02.0" made me think that something was wrong with the latest Intel video drivers.

I have also attached my xorg.conf file, which has very little deviance from defaults (most notably EXA acceleration). The output of lspci -vv is also included.

In short, I suspect that this problem is due to Intel 2D causing Xorg to do a lot of redraws. Text in particular seems to be slow to process (slow konqueror scrolling).

With some research, I also found that framebuffer compression is disabled in the 2.6.3 driver due to a bug. That may have caused an additional spike in power draw.

At the time of posting, all packages were the latest in the repositories. The kernel version is 2.6.28-11-generic.

[lspci]
00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 0c)
     Subsystem: Lenovo Device 20b3
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c)
     Subsystem: Lenovo Device 20b5

[Richard Guo (rfguo)]

powertop - AC

[Richard Guo (rfguo)]

powertop - battery

[Richard Guo (rfguo)]

xorg.conf

[Richard Guo (rfguo)]

top

[Richard Guo (rfguo)]

In comparison, I have attached the powertop results after downgrading to Intel 2.4 drivers (before the intrusive GEM changes). Power use has greatly decreased to below the level of Hardy. top also shows only 1-2% cpu activity for Xorg.

[valereo (kuznetsov-vv)]

i have the same trouble with high cpu usage of Xorg, when moving windows
or scrolling pages in firefox

[valereo (kuznetsov-vv)]

in Ubuntu 9.04 RELEASE the same problem
hardware notebook IBM lenovo X61s, i965GM

when system is idle:
glxgears
3814 frames in 5.0 seconds = 762.697 FPS
3870 frames in 5.0 seconds = 773.926 FPS

and when i move any window on screen (terminal or open folder):
glxgears
442 frames in 5.0 seconds = 88.394 FPS
389 frames in 5.0 seconds = 77.557 FPS
371 frames in 5.0 seconds = 73.928 FPS

and Xorg at this time %CPU > 56

[Mihai Chezan (mihai-chezan)]

I have the same problem. Today I've updated from 8.10 to 9.04 and I experience high CPU usage by XOrg process (issues that with 8.10 I didn't had).
Youtube HD videos don't work (when I click on HD the video doesn't show for some time, then when it does I have video tear and un-sync audio). The normal videos work but still high CPU (XOrg uses about 60% CPU). I tried using UXA but it was worse than EXA+greedy.

The computer is a Acer Aspire 5315 laptop.
lspci:
00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)

Let me know if I can provide more info.

[Patola (patola)]

This is affecting me too. I tried different acceleration methods in xorg.conf - XAA, EXA and UXA - and all are *VERY* slow, almost unbearably slow. I use KDE effects on and yakuake/konsole take forever just to go from one tab to the other (shift-arrows). Everything feels slower, much slower, Xorg takes too much CPU time and so on. Please try and resolve this bugs, I love Ubuntu but this is my primary work laptop and if I can't use it for real production work I'll have to use another distribution. This is not only important to me, it is essential for my continued usage of Ubuntu...

[Patola (patola)]

Sorry... Forgot to say, using Kubuntu 9.04 RC and I also have a T61p with an Intel GM965 Graphics card.

[Mihai Chezan (mihai-chezan)]

@Richard Guo: can you tell me please how can I downgrade to Intel 2.4 drivers? I want to test it on my laptop to see if it would fix the performance problems.

[Richard Guo (rfguo)]

https://wiki.ubuntu.com/ReinhardTartler/X/RevertingIntelDriverTo2.4

[valereo (kuznetsov-vv)]

Reverting to 2.4 didn't help me. Xorg still high cpu using

[Mihai Chezan (mihai-chezan)]

Thank you Richard for the link but unfortunately reverting to 2.4 didn't help (in fact the performance was worse).

[Ben (midfield)]

I can confirm on 9.04 Xubuntu on a Dell 700m (Intel 82852/855GM). Scrolling in a terminal window causes spikes in Xorg CPU usage. This is making it hard for me to use my computer. I'm not sure if it makes a difference but I'm using a dual head setup with xrandr.

[Bryce Harrington (bryce)]

Richard, would you mind testing if the issue still occurs with UXA on the 2.6.3 driver?

Since you see the issue go away by going to 2.4, while others didn't, it sounds like they may be having a separate problem.

[Shashank Chintalagiri (shashank-chintalagiri)]

The downgrade to 2..4 did not help me either. In fact, it made things worse. The bootm line is that cpu usage was minimal on 8.10, and immediately on upgrade to 9.04, the X process's cpu usage shot up to a time average of about 50% of one core (of a 2.0 GHz Core2Duo, 4 MB L2). Downgrading brought the time average cpu usage of the X process to around 80% of one core.

While I see the merit in trying to narrow down the cause of the problem, I honestly dont buy the 'it must be some other problem that other people have' . The problem started in the same way for everybody, and its possible in a specific use case the older driver is able to avoid some other bug that was introduced.

[Richard Guo (rfguo)]

UXA on 2.6.3 changed nothing compared to EXA. glxgears performance is down slightly. No change to video viewing. CPU usage is still 8% when running top (too much CPU for redrawing the text there, I suppose). Spikes up to 50% when viewing a webpage using Firefox. No change to values in powertop either. I'd suspect it's something in the xserver, but I did not notice high cpu usage on other machines using nvidia proprietary drivers or ati OSS drivers.

[Bryce Harrington (bryce)]

> While I see the merit in trying to narrow down the cause of the problem, I honestly dont buy the 'it must be some other problem that other people have' . The problem started in the same way for everybody, and its possible in a specific use case the older driver is able to avoid some other bug that was introduced.

Here's why I say that. Let's say you do have the exact problem. Great, so we focus on the original reporter's bug, and when it's solved, everyone else's issue must also be solved so we close the bug and move on.

However, let's say your issue is *not* the exact same problem. Then when we fix the original person's bug, yours remains unfixed and uninvestigated. The bug gets closed, and since there is not a bug report associated with your problem, your issue falls through the cracks and never gets solved. Maybe you would reopen this bug with a complaint that the fix didn't solve it for you, but well now the bug is a mess of comments from people who have at least 2 different bugs (probably more), and it's hard to follow, and we'd probably just re-close the bug and tell you to send a separate report anyway. You may have saved the effort of filing a new bug, but weeks or months of delay have been added to getting your issue examined.

Maybe this is fine - you may want to wait and see if the fix to this bug solves your issue, and only after that bother to take the time to provide the necessary info and do the troubleshooting and whatnot. That's fine, but in this case please just lurk quietly. :-)

Now consider the case that I say you have a separate issue, and you take some time to make a separate report, but it ends up being the same issue. First, if we can determine definitively that you do have the same issue, then we can dupe your new bug to this one with confidence that it's solved; and if not, your bug can easily be reopened. Second, if we don't dupe them, then having two bugs opened on the same issue means the issue will be looked at from two angles; maybe it doesn't double the chance of getting it solved, but it certainly improves the chances. Third, even if your new report was to get ignored, at least you'll still benefit from the fix once the original one is solved.

So, I hope you understand that when I say you probably have a separate issue, it is stated in an attempt to HELP you get your issue fixed, not to brush you off. If we just blindly assume you have the same problem, and you don't, it risks sweeping your issue under the carpet.

[valereo (kuznetsov-vv)]

i had this problems on 9.04 Gnome

[Ben (midfield)]

i have this problem on 9.04 xubuntu.

b

On Tue, May 12, 2009 at 7:31 PM, valereo <email address hidden> wrote:
> i had this problems on 9.04 Gnome
>
> --
> [i965] Kubuntu: High %CPU/Power Usage unless downgrade to 2.4 (UXA/EXA)
> https://bugs.launchpad.net/bugs/364359
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Ramon Casha (rcasha)]

I have this same problem with Jackelope, Gnome, Compaq 6710b laptop (intel dual core) 4GB ram, i965 graphics chipset. No compiz.

Since some documents pointed out that it might be caused by other processes, I started killing all my processes one by one until I only had the gnome-panel and terminal left, and CPU usage was still above 50% for the Xorg process.

The CPU usage varies wildly, going from 5% to 90% in a matter of seconds, and it doesn't seem to depend on anything I might be doing.

[Richard Guo (rfguo)]

Using UXA with Intel 2.7.1 drivers and libdrm 2.4.9, I have reduced power consumption (13 W) and Xorg in the 2-5% range on idle. 3D performance is much higher (faster than it ever was), though it's not reflected in glxgears. There is the X freeze bug every few hours or so, though.

[Bryce Harrington (bryce)]

[This is an automatic notification.]

A new major version of the -intel driver is now available in Karmic.

This version includes a major reworking of the acceleration
architecture, which resolves a huge number of issues. We do not know
whether it resolves the issue you reported.

Would you mind testing Karmic Alpha-2 and seeing if it is still a
problem? CD ISO images are available here:

  http://cdimages.ubuntu.com/releases/karmic/

If the issue can still be reproduced on karmic, please report here with
your findings, and attach a fresh Xorg.0.log from your test, and we will
be able to forward the bug upstream.

Otherwise, if the bug no longer exists in Karmic, let us know that as
well.

In the off chance you encounter different bugs while attempting to test
Karmic, please report those as new bug reports.

[Bryce Harrington (bryce)]

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

It seems likely to me this bug is gone; the -intel driver has improved immensely in Karmic and a lot of bugs are being reported as no longer present. So hopefully that's the case here too.

[Richard Guo (rfguo)]

I've checked out Karmic Alpha 3 with Kubuntu using Mesa 7.5 and (I think) Intel video drivers 2.8.0. There is no more high CPU usage for idle Xorg. % CPU being used hovers between 0-1%.