timerfd: Allow timers to be cancelled when clock was set
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · tip-bot for Thomas Gleixner
Commit-ID: 99ee5315dac6211e972fa3f23bcc9a0343ff58c4 Gitweb: http://git.kernel.org/tip/99ee5315dac6211e972fa3f23bcc9a0343ff58c4 Author: Thomas Gleixner <[email protected]> AuthorDate: Wed, 27 Apr 2011 14:16:42 +0200 Committer: Thomas Gleixner <[email protected]> CommitDate: Mon, 2 May 2011 21:39:15 +0200
Quoted 8 lines
timerfd: Allow timers to be cancelled when clock was set
Some applications must be aware of clock realtime being set backward. A simple example is a clock applet which arms a timer for the next minute display. If clock realtime is set backward then the applet displays a stale time for the amount of time which the clock was set backwards. Due to that applications poll the time because we don't have an interface.
Shouldn't that clock applet use CLOCK_MONOTONIC for the timer anyway?
Furthermore, weren't there patches to provide clkadjust notifiers? In which case we can have the app woken up and it can fiddle its own timers.
Quoted 3 lines
Extend the timerfd interface by adding a flag which puts the timer onto a different internal realtime clock. All timers on this clock are expired whenever the clock was set.
I don't much like adding random clocks like that, the extra timer base makes many timer operations more expensive, and I really don't see this being worth it :/
Quoted 10 lines · Peter Zijlstra
Quoted 9 lines · tip-bot for Thomas Gleixner
Commit-ID: 99ee5315dac6211e972fa3f23bcc9a0343ff58c4
Gitweb: http://git.kernel.org/tip/99ee5315dac6211e972fa3f23bcc9a0343ff58c4
Author: Thomas Gleixner <[email protected]>
AuthorDate: Wed, 27 Apr 2011 14:16:42 +0200
Committer: Thomas Gleixner <[email protected]>
CommitDate: Mon, 2 May 2011 21:39:15 +0200timerfd: Allow timers to be cancelled when clock was set
Quoted 8 lines
Quoted 6 lines
Some applications must be aware of clock realtime being set backward. A simple example is a clock applet which arms a timer for the next minute display. If clock realtime is set backward then the applet displays a stale time for the amount of time which the clock was set backwards. Due to that applications poll the time because we don't have an interface.
Shouldn't that clock applet use
CLOCK_MONOTONICfor the timer anyway?
Like: Hey let's meet at the bar 5 hours after bootup? :)
Kay
Quoted 18 lines · Kay Sievers
Quoted 17 lines · Peter Zijlstra
Quoted 15 lines · tip-bot for Thomas Gleixner
Commit-ID: 99ee5315dac6211e972fa3f23bcc9a0343ff58c4 Gitweb: http://git.kernel.org/tip/99ee5315dac6211e972fa3f23bcc9a0343ff58c4 Author: Thomas Gleixner <[email protected]> AuthorDate: Wed, 27 Apr 2011 14:16:42 +0200 Committer: Thomas Gleixner <[email protected]> CommitDate: Mon, 2 May 2011 21:39:15 +0200timerfd: Allow timers to be cancelled when clock was set
Some applications must be aware of clock realtime being set backward. A simple example is a clock applet which arms a timer for the next minute display. If clock realtime is set backward then the applet displays a stale time for the amount of time which the clock was set backwards. Due to that applications poll the time because we don't have an interface.
Quoted 3 lines
Quoted 1 line
Shouldn't that clock applet use
CLOCK_MONOTONICfor the timer anyway?Like: Hey let's meet at the bar 5 hours after bootup? :)
Uhm, the example was a timer to update the displayed time, so a timer
like: wake me next minute, suffices.
The whole what to do with appointments when switching timezones wasn't mentioned, but that too should be able to be sorted with a clkadjust notifier.
Quoted 19 lines · Peter Zijlstra
Quoted 18 lines · Kay Sievers
Quoted 17 lines · Peter Zijlstra
Quoted 15 lines · tip-bot for Thomas Gleixner
Commit-ID: 99ee5315dac6211e972fa3f23bcc9a0343ff58c4
Gitweb: http://git.kernel.org/tip/99ee5315dac6211e972fa3f23bcc9a0343ff58c4
Author: Thomas Gleixner <[email protected]>
AuthorDate: Wed, 27 Apr 2011 14:16:42 +0200
Committer: Thomas Gleixner <[email protected]>
CommitDate: Mon, 2 May 2011 21:39:15 +0200timerfd: Allow timers to be cancelled when clock was set
Some applications must be aware of clock realtime being set backward. A simple example is a clock applet which arms a timer for the next minute display. If clock realtime is set backward then the applet displays a stale time for the amount of time which the clock was set backwards. Due to that applications poll the time because we don't have an interface.
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Shouldn't that clock applet use
CLOCK_MONOTONICfor the timer anyway?Like: Hey let's meet at the bar 5 hours after bootup? :)
Uhm, the example was a timer to update the displayed time, so a timer
like: wake me next minute, suffices.
No, fixed time spans have never been a problem, and are not the example here. It's about the normal wall clock, that wakes up every minute and updates the numbers on the screen.
Kay
Quoted 4 lines · Kay Sievers
No, fixed time spans have never been a problem, and are not the example here. It's about the normal wall clock, that wakes up every minute and updates the numbers on the screen.
'wakes up every minute' sounds like a fixed time interval to me.
Anyway, I still don't agree with the current implementation, its adding overhead to timer fast-paths for a definite slow-path.
Quoted 7 lines · Peter Zijlstra
Quoted 4 lines · Kay Sievers
No, fixed time spans have never been a problem, and are not the example here. It's about the normal wall clock, that wakes up every minute and updates the numbers on the screen.
'wakes up every minute' sounds like a fixed time interval to me.
Right, but if the wall clock changes, it must not wait for the full minute to update the numbers, they need to update immediately with the new wall clock time. Stuff woke up every second in the past to do that, but that's not what we want today.
Kay
Quoted 7 lines · Kay Sievers
Quoted 6 lines · Peter Zijlstra
Quoted 4 lines · Kay Sievers
No, fixed time spans have never been a problem, and are not the example here. It's about the normal wall clock, that wakes up every minute and updates the numbers on the screen.
Quoted 6 lines
Quoted 1 line
'wakes up every minute' sounds like a fixed time interval to me.
Right, but if the wall clock changes, it must not wait for the full minute to update the numbers, they need to update immediately with the new wall clock time. Stuff woke up every second in the past to do that, but that's not what we want today.
Again, nothing that couldn't be solved with a notifier of sorts.
Quoted 8 lines · Peter Zijlstra
Quoted 7 lines · Kay Sievers
Quoted 6 lines · Peter Zijlstra
Quoted 4 lines · Kay Sievers
No, fixed time spans have never been a problem, and are not the example here. It's about the normal wall clock, that wakes up every minute and updates the numbers on the screen.
Quoted 8 lines
Quoted 6 lines
Quoted 1 line
'wakes up every minute' sounds like a fixed time interval to me.
Right, but if the wall clock changes, it must not wait for the full minute to update the numbers, they need to update immediately with the new wall clock time. Stuff woke up every second in the past to do that, but that's not what we want today.
Again, nothing that couldn't be solved with a notifier of sorts.
Right. What we have with that patch, and what's visible to the outside, is nothing but such a notifier. What kind of interface you have in mind instead?
Kay
Quoted 16 lines · Kay Sievers
Quoted 15 lines · Peter Zijlstra
Quoted 13 lines · Kay Sievers
Quoted 7 lines · Peter Zijlstra
Quoted 4 lines · Kay Sievers
No, fixed time spans have never been a problem, and are not the example here. It's about the normal wall clock, that wakes up every minute and updates the numbers on the screen.
'wakes up every minute' sounds like a fixed time interval to me.
Right, but if the wall clock changes, it must not wait for the full minute to update the numbers, they need to update immediately with the new wall clock time. Stuff woke up every second in the past to do that, but that's not what we want today.
Quoted 5 lines
Quoted 1 line
Again, nothing that couldn't be solved with a notifier of sorts.
Right. What we have with that patch, and what's visible to the outside, is nothing but such a notifier. What kind of interface you have in mind instead?
Dunno, an eventfd that triggers every time someone calls adjtime() and related?
Anything as long as it doesn't increase HRTIMER_MAX_CLOCK_BASES really.
Quoted 17 lines · Peter Zijlstra
Quoted 16 lines · Kay Sievers
Quoted 15 lines · Peter Zijlstra
Quoted 13 lines · Kay Sievers
Quoted 7 lines · Peter Zijlstra
Quoted 4 lines · Kay Sievers
No, fixed time spans have never been a problem, and are not the example here. It's about the normal wall clock, that wakes up every minute and updates the numbers on the screen.
'wakes up every minute' sounds like a fixed time interval to me.
Right, but if the wall clock changes, it must not wait for the full minute to update the numbers, they need to update immediately with the new wall clock time. Stuff woke up every second in the past to do that, but that's not what we want today.
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
Again, nothing that couldn't be solved with a notifier of sorts.
Right. What we have with that patch, and what's visible to the outside, is nothing but such a notifier. What kind of interface you have in mind instead?
Dunno, an eventfd that triggers every time someone calls
adjtime()and related?
I think, we are exactly not interested in adjtime() calls, but only in jumps in wall clock time.
Kay
Quoted 6 lines · Kay Sievers
Quoted 3 lines
Dunno, an eventfd that triggers every time someone calls
adjtime()and related?I think, we are exactly not interested in
adjtime()calls, but only in jumps in wall clock time.
adjtime(), adjtimex() and settimeofday() are afaik the only ways to make walltime jump. Anyway what are you arguing about, don't you want the notification or do you insist on making the kernel slower for the 3 people who care about this daftness?
Quoted 5 lines · Peter Zijlstra
Quoted 4 lines · Kay Sievers
Quoted 3 lines
Dunno, an eventfd that triggers every time someone calls
adjtime()and related?
Quoted 7 lines
Quoted 2 lines
I think, we are exactly not interested in
adjtime()calls, but only in jumps in wall clock time.
adjtime(),adjtimex()andsettimeofday()are afaik the only ways to make walltime jump. Anyway what are you arguing about, don't you want the notification or do you insist on making the kernel slower for the 3 people who care about this daftness?
I want a sane interface to get notified about changes to the time which I asked the kernel to manage for me while I'm sleeping. The interface in this patch does exactly that, in a very nice way.
If you think that needs to change, please discuss/provide alternatives, which we can check if they sufficiently work for us, like we did with this patch.
But please stop rhetorically asking me if I want a slower kernel, and chance your tone. That will get us nowhere.
Kay
Quoted 4 lines · Kay Sievers
If you think that needs to change, please discuss/provide alternatives, which we can check if they sufficiently work for us, like we did with this patch.
Since this is a published interface that's not the way things work, first thing is to revert this to avoid us getting stuck with this crap.
Quoted 3 lines
But please stop rhetorically asking me if I want a slower kernel, and chance your tone. That will get us nowhere.
Ah, we've got our patch and we'll stick to it no matter what the consequences, very good attitude that.
Quoted 8 lines · Peter Zijlstra
Quoted 4 lines · Kay Sievers
If you think that needs to change, please discuss/provide alternatives, which we can check if they sufficiently work for us, like we did with this patch.
Since this is a published interface that's not the way things work, first thing is to revert this to avoid us getting stuck with this crap.
What? That is not merged. Anything that would need fixing can still be fixed. But I guess you need to do more than just calling it 'crap'.
Quoted 7 lines
Quoted 2 lines
But please stop rhetorically asking me if I want a slower kernel, and chance your tone. That will get us nowhere.
Ah, we've got our patch and we'll stick to it no matter what the consequences,
very good attitude that.
It's not my patch. I just like its interface very much.
Kay