• Andrew Morton's avatar
    [PATCH] fix lost_tick detector for speedstep · 48ecce4b
    Andrew Morton authored
    From: john stultz <johnstul@us.ibm.com>
    
    The patch tries to resolve issues caused by running the TSC based lost
    tick compensation code on CPUs that change frequency (speedstep, etc).
    
    Should the CPU be in slow mode when calibrate_tsc() executes, the kernel
    will assume we have so many cycles per tick.  Later when the cpu speeds up,
    the kernel will start noting that too many cycles have past since the last
    interrupt.  Since this can occasionally happen, the lost tick compensation
    code then tries to fix this by incrementing jiffies.  Thus every tick we
    end up incrementing jiffies many times, causing timers to expire too
    quickly and time to rush ahead.
    
    This patch detects when there has been 100 consecutive interrupts where we
    had to compensate for lost ticks.  If this occurs, we spit out a warning
    and fall back to using the PIT as a time source.
    
    I've tested this on my speedstep enabled laptop with success, and others
    laptop users seeing this problem have reported it works for them.  Also to
    ensure we don't fall back to the slower PIT too quickly, I tested the code
    on a system I have that looses ~30 ticks about every second and it can
    still manage to use the TSC as a good time source.
    
    This solves most of the "time doubling" problems seen on laptops.
    Additionally this revision has been modified to use the cleanups made in
    rename-timer_A1.
    48ecce4b
timer.c 1.02 KB