• Steven Rostedt's avatar
    sched_clock: stop maximum check on NO HZ · af52a90a
    Steven Rostedt authored
    Working with ftrace I would get large jumps of 11 millisecs or more with
    the clock tracer. This killed the latencing timings of ftrace and also
    caused the irqoff self tests to fail.
    
    What was happening is with NO_HZ the idle would stop the jiffy counter and
    before the jiffy counter was updated the sched_clock would have a bad
    delta jiffies to compare with the gtod with the maximum.
    
    The jiffies would stop and the last sched_tick would record the last gtod.
    On wakeup, the sched clock update would compare the gtod + delta jiffies
    (which would be zero) and compare it to the TSC. The TSC would have
    correctly (with a stable TSC) moved forward several jiffies. But because the
    jiffies has not been updated yet the clock would be prevented from moving
    forward because it would appear that the TSC jumped too far ahead.
    
    The clock would then virtually stop, until the jiffies are updated. Then
    the next sched clock update would see that the clock was very much behind
    since the delta jiffies is now correct. This would then jump the clock
    forward by several jiffies.
    
    This caused ftrace to report several milliseconds of interrupts off
    latency at every resume from NO_HZ idle.
    
    This patch adds hooks into the nohz code to disable the checking of the
    maximum clock update when nohz is in effect. It resumes the max check
    when nohz has updated the jiffies again.
    Signed-off-by: default avatarSteven Rostedt <srostedt@redhat.com>
    Cc: Steven Rostedt <srostedt@redhat.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
    af52a90a
tick-sched.c 17 KB