Contents
Problem
Many apps on the desktop wake up from sleep too often. It is in the interest of power savings to reduce this as much as possible. Ideally, we will head toward a desktop that remains completely idle when the user isn't interacting with it. Fixing this should theoretically help performance even on busy machines since every wakeup causes an mm change (which flushes the TLB), and also tends to keep the cache populated with crap.
Web Resources
A few resources exist online to help you find problem applications or track down problems in a specific application.
PowerTop utility
http://blogs.gnome.org/view/ryanl/2006/09/18/0 -- kernel patch and utility to find apps with lots of wakeups due to timeouts
http://primates.ximian.com/~federico/news-2006-09.html#polling -- how to find who scheduled timeouts in glib
Known Problems
The tracking bug for all GNOME problems is here: https://bugzilla.gnome.org/show_bug.cgi?id=356586
Applications To Fix
This section should contain applications with timer problems which can easily be fixed. Link to bug reports if applicable.
gnome-terminal (libvte)
FIXED
libvte schedules a timer to make the cursor blink. It does this even when the cursor isn't set to blinking mode and when the window is unfocused (so the cursor wouldn't be blinking anyway). https://bugzilla.gnome.org/attachment.cgi?id=72991&action=diff
Difficult Cases
This section should contain applications with known problems that are difficult to fix and the list of reasons why (ie: what must be overcome in order to fix the problem).
Xorg i810 Driver
The i810 video driver, on laptops, schedules a wakeup once per second. The wakeup causes enabling of the 'SmartSchedule' timer resulting in yet another wakeup 200ms after the first. The purpose of the timer is to run a handler which polls for a number of things:
- lid status (to automatically power the monitor off)
- hotkeys on some laptops
- the state of the monitor ports (for purpose of zero-click monitor hotplugging)
Newer i810 video cards will generates IRQs on all of these events and the kernel DRM driver (which watches this IRQ) could forward these events to the X server entirely removing the need for the poll.
clock applet
FIXED
The clock applet wakes up once per second even when set not to show seconds. The reason for this is because when the user manually changes the time or when the laptop sleeps and then resumes (at a later time) the clock applet wants to show this change right away. If the clock sleeps for 60 seconds then it will show the old time for as long as 60 seconds. One possibility is to have the clock notified when time changes occur. See bug #348749
Python Applications
Programms which use PyGtk or plugins which use PyGtk awake regularly. This is due to the possibility in python to install a python signal handler. The signal is cought and it must be regularly checked if a signal was raised so the python code can run (The python code can't run in the singal handler itself). Now if a signal is raised in a thread other than the main thread (where the gtk main loop runs) no one gets informed about the signal. To do this pygtk has no other posibility than to install a timeout handler and check here the state of the signal flags.
There is some hope to install our own signal handlers which write to a pipe and check is pipe in the main loop: Signals, threads, blocking C functions
Anything using gnome-vfs for file monitoring
Due to limitations in the inotify backend of gnome-vfs frequent polling can occur when you use inotify to monitor files. For example, gnome-panel wakes up about once a second to poll for the 'recently used' list being changed. Problems like this can be solved by registering an inotify watch on the parent directory of the file in question but that uses more inotify handles (of which each user has a limited amount).
Related Projects
Use g_timeout_add_seconds instead g_timeout_add
One of the features of GTK+ is that it provides two timeout functions: g_timeout_add and g_timeout_add_seconds. The difference is much more important than not having to add a "* 1000" in one and not the other. The important thing that the second function does is that it tried to group wake-ups to ensure that the program wakes up as little as possible. This is never perfect, but it's a small thing that can help to save some power and reduce the number of wake-ups. More info and how help here: http://live.gnome.org/GnomeGoals/UseTimeoutAddSeconds