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> 0 1 |-----X----X-------XX----X----X----| <with patch 0 1 |XX--------------------------------| 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.