Messages in this thread | | | From | Kay Sievers <> | Date | Fri, 12 Nov 2010 11:47:57 +0100 | Subject | Re: [PATCHv6 0/7] system time changes notification |
| |
On Thu, Nov 11, 2010 at 22:16, Thomas Gleixner <tglx@linutronix.de> wrote: > B1;2401;0cOn Thu, 11 Nov 2010, Alexander Shishkin wrote: > >> On Thu, Nov 11, 2010 at 03:28:13PM -0500, Valdis.Kletnieks@vt.edu wrote: >> > On Thu, 11 Nov 2010 21:29:55 +0200, Alexander Shishkin said: >> > >> > > Consider we want stuff like "wakeup every day at 3pm", the next wakeup >> > > might be earlier than the timer we calculated last time, on system >> > > time changes. We need to re-calculate it. This is necessary for all >> > > repeating events. >> > > >> > > Say we want to wakeup at 3pm, now it's 4pm, so we schedule it in 23 >> > > hours. Now the system time changes to 2pm, and we would expect to >> > > wakeup in one hour, but we take 25. >> > >> > Sorry, I tuned in late here... >> > >> > So the plan is that if you're not using this new interface, it will go off at >> > the same absolute offset (23 hours after timer was set), but if you're using >> > this interface, your timer event gets interrupted, you get woken up (say) >> > 15 hours into your 23, and it's your job to decide if you need to set a >> > new timer for the remaining 6, 7, 8 hours or some other number? >> >> Yes. This interface doesn't deal with timers, it only provides notifications. > > The notification itself is pointless unless your application is > dealing with timers which need to be adjusted the one way or the > other. > > That said, I'm still not convinced that this usecase justifies a new > systemcall. > > 1) We can make timers wake up when a clock change happens
That would be fine too. We just need to wake up somehow and then can find out ourselves what has happened underneath us.
> 2) Can't we use existing notification stuff like uevents or such ?
Uevents are heavy and very expensive to handle in userspace. Udev wakes up all of these and runs stuff. They can only be used for device discovery or some low-frequency state change notification, nothing else. If there is the slightest chance that they might happen at a very high frequency, they might bring an entire box down. It's really not what they are made for.
Can't we just let poll() on timerfd return POLLPRI|POLLERR if the time shifted to something that needs re-calculation in the requesting process?
Kay
| |