• Frederic Weisbecker's avatar
    nohz: Fix collision between tick and other hrtimers, again · 411fe24e
    Frederic Weisbecker authored
    This restores commit:
    
      24b91e36: ("nohz: Fix collision between tick and other hrtimers")
    
    ... which got reverted by commit:
    
      558e8e27: ('Revert "nohz: Fix collision between tick and other hrtimers"')
    
    ... due to a regression where CPUs spuriously stopped ticking.
    
    The bug happened when a tick fired too early past its expected expiration:
    on IRQ exit the tick was scheduled again to the same deadline but skipped
    reprogramming because ts->next_tick still kept in cache the deadline.
    This has been fixed now with resetting ts->next_tick from the tick
    itself. Extra care has also been taken to prevent from obsolete values
    throughout CPU hotplug operations.
    
    When the tick is stopped and an interrupt occurs afterward, we check on
    that interrupt exit if the next tick needs to be rescheduled. If it
    doesn't need any update, we don't want to do anything.
    
    In order to check if the tick needs an update, we compare it against the
    clockevent device deadline. Now that's a problem because the clockevent
    device is at a lower level than the tick itself if it is implemented
    on top of hrtimer.
    
    Every hrtimer share this clockevent device. So comparing the next tick
    deadline against the clockevent device deadline is wrong because the
    device may be programmed for another hrtimer whose deadline collides
    with the tick. As a result we may end up not reprogramming the tick
    accidentally.
    
    In a worst case scenario under full dynticks mode, the tick stops firing
    as it is supposed to every 1hz, leaving /proc/stat stalled:
    
          Task in a full dynticks CPU
          ----------------------------
    
          * hrtimer A is queued 2 seconds ahead
          * the tick is stopped, scheduled 1 second ahead
          * tick fires 1 second later
          * on tick exit, nohz schedules the tick 1 second ahead but sees
            the clockevent device is already programmed to that deadline,
            fooled by hrtimer A, the tick isn't rescheduled.
          * hrtimer A is cancelled before its deadline
          * tick never fires again until an interrupt happens...
    
    In order to fix this, store the next tick deadline to the tick_sched
    local structure and reuse that value later to check whether we need to
    reprogram the clock after an interrupt.
    
    On the other hand, ts->sleep_length still wants to know about the next
    clock event and not just the tick, so we want to improve the related
    comment to avoid confusion.
    Reported-and-tested-by: default avatarTim Wright <tim@binbash.co.uk>
    Reported-and-tested-by: default avatarPavel Machek <pavel@ucw.cz>
    Reported-by: default avatarJames Hartsock <hartsjc@redhat.com>
    Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Acked-by: default avatarRik van Riel <riel@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: stable@vger.kernel.org
    Link: http://lkml.kernel.org/r/1492783255-5051-2-git-send-email-fweisbec@gmail.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
    411fe24e
tick-sched.h 2.56 KB