burning cpu and battery on the gnome desktop

last night seb128 asked me for advice on how he could tell if gnome-vfs was using inotify or gamin as its backend for file monitoring. i didn’t really know, so i suggested stracing gnomevfs-monitor.

this is when i found out that the inotify code in dapper’s gnome-vfs wakes up 10 times a second. i understand this to be because it does some polling for non-existant files and also has an internal timer to match move_from and move_to events.

this is a problem. 9 applications on my system right now are using file monitoring and suffering this problem. list is as follows:

  • panel
  • nautilus
  • settings-daemon
  • ephy
  • update-notify
  • vfs-daemon
  • seahorse-agent
  • muine
  • deskbar

this alone causes my system to wake up 90 times per second.

at guadec i also talked to mclasen about another bug. gtk in dapper wakes up whenever a mouse button is clicked or a modifier key is pressed. this means that every single application on your desktop wakes up every time you press or release shift. ow. mclasen fixed this bug within a very impressive amount of time and the fix will be in gtk 2.10. dapper users are left burning cpu for the time being.

i’ve been going around stracing random pid’s of desktop processes. i’ve found some other offenders.

  • gnome-power-manager wakes up twice per second to do something
  • battery applet wakes up once per second to do something
  • clock-applet wakes up once per second to update the time even when seconds aren’t shown
  • gajim wakes up 10+ times per second for some unknown reason
  • at-spi-registryd wakes up more like 20+ times a second (?!?)
  • gss seems to talk to x11 once per second (presumably to ask if anything has happened). i don’t understand why it has to do this so often.

so all in all gnome is causing my computer to wake up about 200 times a second when totally idle. since this is happening in a lot of different processes, that’s one heck of a lot of context switches.

i did a check. in a loop (with sleep 10s) i catted the contents of the acpi battery state in /proc. i did this with gnome running and with a failsafe x session with xterm. gnome causes my laptop to use a couple of watts more power.

i also was talking to mjg59 about this earlier today. according to him, circa 2.6.19 we’ll see a new kernel feature by which the ‘hz’ timer that runs at a constant rate will be disabled. the idea is that we can use the new hightech timers we have to schedule timer interrupts only when needed. this means that except when in userspace (for preemption purposes) or waiting for some specific event the timer will be disabled and the cpu will be totally idle until the next irq comes in.

if we can reduce the number of wakes-up the desktop does (to say, zero times per second) then we can reduce the number of times the kernel has to wake the cpu up at all. even without the new timer tech there’s a noticable (albiet small) change in battery consumption. with the new timers, not waking up will become increasingly important.

this post is a plea. please fix your apps to never wake up unless the user does something to them. my laptop’s battery will thank you.

ps: the best way to find out how often your app is running is to use strace. you have two options here. you can either run your application directly under strace as follows:


strace yourapp

or you can attach strace to a running application by its pid:


strace -p `pidof yourapp`

if you see poll( or select( and a long wait then your app is sleeping (good!). if you see lots of activity when you’re not otherwise interacting with your application then you’ve got trouble. fix it!