• F
    nohz: Fix buggy tick delay on IRQ storms · f99973e1
    Frederic Weisbecker 提交于
    When the tick is stopped and we reach the dynticks evaluation code on
    IRQ exit, we perform a soft tick restart if we observe an expired timer
    from there. It means we program the nearest possible tick but we stay in
    dynticks mode (ts->tick_stopped = 1) because we may need to stop the tick
    again after that expired timer is handled.
    
    Now this solution works most of the time but if we suffer an IRQ storm
    and those interrupts trigger faster than the hardware clockevents min
    delay, our tick won't fire until that IRQ storm is finished.
    
    Here is the problem: on IRQ exit we reprog the timer to at least
    NOW() + min_clockevents_delay. Another IRQ fires before the tick so we
    reschedule again to NOW() + min_clockevents_delay, etc... The tick
    is eternally rescheduled min_clockevents_delay ahead.
    
    A solution is to simply remove this soft tick restart. After all
    the normal dynticks evaluation path can handle 0 delay just fine. And
    by doing that we benefit from the optimization branch which avoids
    clock reprogramming if the clockevents deadline hasn't changed since
    the last reprog. This fixes our issue because we don't do repetitive
    clock reprog that always add hardware min delay.
    
    As a side effect it should even optimize the 0 delay path in general.
    Reported-and-tested-by: NOctavian Purdila <octavian.purdila@nxp.com>
    Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Rik van Riel <riel@redhat.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/1496328429-13317-1-git-send-email-fweisbec@gmail.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
    f99973e1
tick-sched.c 31.7 KB