On Thu, Apr 20, 2017 at 07:56:22PM +0200, Thomas Gleixner wrote:
> On Thu, 20 Apr 2017, Frederic Weisbecker wrote:
>
> > So far we have run into too much troubles with the optimization path
> > that skips reprogramming the clock on IRQ exit when the expiration
> > deadline hasn't changed. If by accident the cached deadline happens to
> > be out of sync with the hardware deadline, the buggy result and its
> > cause are hard to investigate. So lets detect and warn about the issue
> > early.
> >
> > Signed-off-by: Frederic Weisbecker <fweisbec@xxxxxxxxx>
> > Cc: Tim Wright <tim@xxxxxxxxxxxxx>
> > Cc: Pavel Machek <pavel@xxxxxx>
> > Cc: James Hartsock <hartsjc@xxxxxxxxxx>
> > Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
> > Cc: Rik van Riel <riel@xxxxxxxxxx>
> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
> > Cc: Ingo Molnar <mingo@xxxxxxxxxx>
> > ---
> > kernel/time/tick-sched.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
> > index 502b320..eb1366e 100644
> > --- a/kernel/time/tick-sched.c
> > +++ b/kernel/time/tick-sched.c
> > @@ -783,8 +783,10 @@ static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
> > tick = expires;
> >
> > /* Skip reprogram of event if its not changed */
> > - if (ts->tick_stopped && (expires == ts->next_tick))
> > + if (ts->tick_stopped && (expires == ts->next_tick)) {
> > + WARN_ON_ONCE(dev->next_event > ts->next_tick);
>
> What about handling it proper ? dev->next_event might be KTIME_MAX,
> i.e. no more event for the next 500+ years.
I thought I handled this case, what I'm I missing?
> Thanks,
>
> tglx