My interpretation of the api is:
* round_jiffies() - timer wants to wakeup but isn't precise about when so schedule
on next second when system will wake up anyway;
e.g why meetings are usually scheduled on the hour
* deferrable - timer doesn't have to really wakeup but wants to happen near
a particular time. e.g. "I'll meet you at the pub around 8pm"
If this is the case then the whole usage of round_jiffies() is bogus. All users of round_jiffies()
should just be converted to deferrable?? I am a bit concerned that if deferrable gets used everywhere
then a strange situation would occur where all timers were waiting for some other timer to finally
happen, kind of a wierd timelock situation. Like the old chip/dale cartoon:
"you first, no you first, after you mister chip, no after you mister dale,..."
that's a dangerous situation indeed and I'd really like to know what the limits
are for deferring deferrable timers.... Arjan, do you know? Anyone?
I don't see a danger just yet on normal systems - I get something like 10 wakeups
per second from just the kernel (acpi, ahci, usb) on most my systems which
guarantees that the watchdog runs often enough, but for embedded systems and
critical timers in other drivers this may be an issue quickly