On Mon, 2011-05-02 at 19:44 +0000, tip-bot for Thomas Gleixner wrote:
> 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
>
> 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.
> 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 :/
On Wed, May 11, 2011 at 12:23, Peter Zijlstra <[email protected]> wrote:
> On Mon, 2011-05-02 at 19:44 +0000, tip-bot for Thomas Gleixner wrote:
>> 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
>>
>> 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?
Like: Hey let's meet at the bar 5 hours after bootup? :)
Kay
On Wed, 2011-05-11 at 13:58 +0200, Kay Sievers wrote:
> On Wed, May 11, 2011 at 12:23, Peter Zijlstra <[email protected]> wrote:
> > On Mon, 2011-05-02 at 19:44 +0000, tip-bot for Thomas Gleixner wrote:
> >> 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
> >>
> >> 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?
>
> 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.
On Wed, May 11, 2011 at 15:45, Peter Zijlstra <[email protected]> wrote:
> On Wed, 2011-05-11 at 13:58 +0200, Kay Sievers wrote:
>> On Wed, May 11, 2011 at 12:23, Peter Zijlstra <[email protected]> wrote:
>> > On Mon, 2011-05-02 at 19:44 +0000, tip-bot for Thomas Gleixner wrote:
>> >> 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
>> >>
>> >> 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?
>>
>> 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
On Wed, 2011-05-11 at 15:52 +0200, Kay Sievers wrote:
>
> 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.
On Wed, May 11, 2011 at 16:01, Peter Zijlstra <[email protected]> wrote:
> On Wed, 2011-05-11 at 15:52 +0200, Kay Sievers wrote:
>>
>> 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
On Wed, 2011-05-11 at 16:22 +0200, Kay Sievers wrote:
> On Wed, May 11, 2011 at 16:01, Peter Zijlstra <[email protected]> wrote:
> > On Wed, 2011-05-11 at 15:52 +0200, Kay Sievers wrote:
> >>
> >> 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.
Again, nothing that couldn't be solved with a notifier of sorts.
On Wed, May 11, 2011 at 16:30, Peter Zijlstra <[email protected]> wrote:
> On Wed, 2011-05-11 at 16:22 +0200, Kay Sievers wrote:
>> On Wed, May 11, 2011 at 16:01, Peter Zijlstra <[email protected]> wrote:
>> > On Wed, 2011-05-11 at 15:52 +0200, Kay Sievers wrote:
>> >>
>> >> 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.
>
> 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
On Wed, 2011-05-11 at 16:32 +0200, Kay Sievers wrote:
> On Wed, May 11, 2011 at 16:30, Peter Zijlstra <[email protected]> wrote:
> > On Wed, 2011-05-11 at 16:22 +0200, Kay Sievers wrote:
> >> On Wed, May 11, 2011 at 16:01, Peter Zijlstra <[email protected]> wrote:
> >> > On Wed, 2011-05-11 at 15:52 +0200, Kay Sievers wrote:
> >> >>
> >> >> 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.
> >
> > 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.
On Wed, May 11, 2011 at 16:48, Peter Zijlstra <[email protected]> wrote:
> On Wed, 2011-05-11 at 16:32 +0200, Kay Sievers wrote:
>> On Wed, May 11, 2011 at 16:30, Peter Zijlstra <[email protected]> wrote:
>> > On Wed, 2011-05-11 at 16:22 +0200, Kay Sievers wrote:
>> >> On Wed, May 11, 2011 at 16:01, Peter Zijlstra <[email protected]> wrote:
>> >> > On Wed, 2011-05-11 at 15:52 +0200, Kay Sievers wrote:
>> >> >>
>> >> >> 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.
>> >
>> > 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
On Wed, 2011-05-11 at 16:53 +0200, Kay Sievers wrote:
>
> > 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?
On Wed, May 11, 2011 at 17:11, Peter Zijlstra <[email protected]> wrote:
> On Wed, 2011-05-11 at 16:53 +0200, Kay Sievers wrote:
>>
>> > 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?
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
On Wed, 2011-05-11 at 17:17 +0200, Kay Sievers wrote:
>
> 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.
>
> 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.
On Wed, May 11, 2011 at 17:31, Peter Zijlstra <[email protected]> wrote:
> On Wed, 2011-05-11 at 17:17 +0200, Kay Sievers wrote:
>>
>> 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'.
>> 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