Description of problem:
The patch that I will attach adds a variant of g_timeout_add to the glib API,
g_timeout_add_approx(). The goal of the _approx version is to allow the
application to indicate that the timeout is an approximate value, and that the
application doesn't care a great deal about the exact time this timer will
fire. The implementation in the patch uses this "no need to be exact"
information to schedule the timer only on "whole wallclock seconds".
The effect of this is that applications that have multiple such timers running
in parallel will have less context switches/wakeups because the timers will
naturally group together this way into one wakeup moment.
The effect is bigger than just the single app; on a system level, all such
timers from all glib using applications will wake up around the same time in
the second. This is an advantage for the following reason: (ascii art of 1
second, the X denotes a wakeup of any app)
<current situation; random wakeups during the second>
in the <with patch> situation the processor and the system can sleep for a much
longer time, which allows for much greater power savings than the continuously
waking up case.
This is useful for power savings, but also for the virtualization case where
frequent wakeups are also a cause for performance costs.
Created attachment 135424 [details]
add g_timeout_approx() and friends
I think the docs ought to say something more about the adjustments which glib
may do to the timeout.
Actually, lets track this upstream.