Update Manager causes high Xorg CPU usage when checking for updates

The only thing I can think of is the download progress bar that may cause high load on the xserver. I do not think this is a update-manager bug, more either theme, gtk or the xserver. What card/driver are you using?

That progress bar doesn't cause as much load anywhere else... and it
seems to be pretty consistent across machines and themes. I'll
confirm that later.
I'm using an Intel card
00:02.0 VGA compatible controller: Intel Corporation Mobile
GM965/GL960 Integrated Graphics Controller (rev 0c)
With the Intel driver in Jaunty, using UXA. This has been a problem
in Intrepid and before, too.

I'v tried changing the human theme's engine used for the progressbar from murrine to clearlooks/industrial but still the cpu usage is high.

Another issue is , the same progressbar is used while downloading the packages , but that doesnt cause raise in cpu usage.

So this doesnt seem theme dependant.

The update-apt-xapian cpu usage is very high in during the initial update process but then usage drops while xorg remains high.

I commited a fix for this in my synaptic branch at https://code.edge.launchpad.net/synaptic (rev 1738). Its probably too late for this in karmic, I will upload it into my PPA for testing.

The PPA is availabe via "sudo add-apt-repository ppa:mvo"

Michael Vogt ,
I tried the ppa , synaptic (0.62.7ubuntu6) to 0.62.7ubuntu7~ppa1 , but it doesnt seem to solve the problem.
Still i notice the xorg consuming ~25% CPU [same as before.]

Could this be SRU'd? It seems like a rather serious issue, and has a very wide impact.

@Chow - unfortuantely we do not know what is causing the problem yet. mac_v says the version in my PPA does not fix the bug.

I've noticed this problem as well (with the radeon and intel drivers on separate machines). My impression is that the GtkProgressbar widget is causing the excessive CPU usage (at least during the installation of updates).

@Conn: I commited a bit of code to bzr that may help with the problem. I uploaded it as 0.63ubuntu4 to lucid, please let me know if it makes a difference.

@mvo , 0.63ubuntu4 in lucid , doesnt help either :( [ATI radeon drivers]
Still the same or maybe even worse? now i notice Xorg CPU usage is 30% [Just noticed my previous comment where i mentioned 25%]

I ran across this bug because bug #528925 makes this very evident. It seems to me this bug is actually in synaptic as that is another of the big CPU consumers in top and I can reproduce the same behavior by running "Reload" in synaptic. I'm guessing update-manager is actually calling synaptic to do the work.

I tried strace on synaptic and it seems to be doing poll() in a tight loop and getting EAGAIN repeatedly. It should probably be doing select() instead or at least sleeping for a little bit between invocations. No need to update the status bar as fast as possible, it only slows down actual work, like installing packages. :)

I grepped the synaptic source and couldn't find any calls to poll() so I guess it is being called inside a library. My gdb skills aren't enough to track that down.

I've instructed myself a bit on how to use gdb and went after the bug. Here's a stack trace of the bug in action:

(gdb) bt
#0 0x00007ffff31a9c53 in __select_nocancel ()
    at ../sysdeps/unix/syscall-template.S:82
#1 0x00007ffff7b6cd69 in pkgAcquire::Run (this=0x7fffffffc830,
    PulseIntervall=<value optimized out>) at acquire.cc:346
#2 0x00007ffff7b666c2 in ListUpdate (Stat=<value optimized out>, List=...,
    PulseInterval=5000) at algorithms.cc:1367
#3 0x00000000004653a9 in RPackageLister::updateCache (
    this=<value optimized out>, status=0xa80d00, error=...)
    at rpackagelister.cc:1301
#4 0x0000000000440148 in RGMainWindow::cbUpdateClicked (
    self=<value optimized out>, data=0x75ba70) at rgmainwindow.cc:2999

What's happening here is that synaptic is using the apt libraries to run a tight loop using select to update the progress bar status. In RPackageLister::updateCache, line 1301 is:

bool res = ListUpdate(*status, *_cache->list(), 5000);

That eventually gets used as tv.tv_usec in a select() call making this a select loop where each select only waits for 0.005 seconds. I tried bumping that value to 500000 (0.5 seconds) and it solves the CPU problem but because the code is single threaded it slows down the whole interface. A more involved patch is needed.

I'm marking this bug as confirmed as several others are facing the bug.

Could you please also assign the bug to synaptic? See my comment above for how that's where the bug is.

I uploaded a new synaptic into maverick that may fix the problem, please let me know, if it does we can consider a backport to lucid-proposed.

The new synaptic still causes high Xorg CPU usage (up to 80%). Still not fixed.

Installed synaptic (0.63.1ubuntu12) in Lucid and tested it.
Now I dont have any cpu spike as earlier. Previously the synaptic and Xorg each would use 20% CPU. But now none of those problems.

/usr/lib/atp/methods/https alone has a spike for 1-2 sec [which i dont think is related and probably existed earlier as well]

But no problems of a constant CPU[Xorg/Synaptic] rise as in earlier versions of synaptic.

Right, 0.63.1ubuntu12 loads Xorg to a lesser extent. I've previously commented with 0.63.1ubuntu11 still in my system.

The latest version does not even trigger CPU freqency scaling, so it's better than nothing.

I'm also experiencing this bug, and have been for months, but I haven't had a shred of time to do anything about it. For me, Xorg cpu usage goes as high as 96%, and the only thing that I can do in those cases is log out of gnome and log back in. It's a major hinderance to essentially everything.

just for the record, i'm using an eee 701 with the i915 driver.