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.
Acked-by: Rik van Riel <[email protected]> Signed-off-by: Frederic Weisbecker <[email protected]> Cc: Tim Wright <[email protected]> Cc: Pavel Machek <[email protected]> Cc: James Hartsock <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Ingo Molnar <[email protected]> --- kernel/time/tick-sched.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c index 502b320..be7ca4d 100644 --- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -783,8 +783,13 @@ 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)) - goto out; + if (ts->tick_stopped && (expires == ts->next_tick)) { + /* Sanity check: make sure clockevent is actually programmed */ + if (likely(dev->next_event <= ts->next_tick)) + goto out; + + WARN_ON_ONCE(1); + } /* * nohz_stop_sched_tick can be called several times before -- 2.7.4
