[lkml]   [2004]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: lost timer check in 2.6.7
    On Wed, Jun 16, 2004 at 01:19:12PM +0200, Andi Kleen wrote:
    > 2.6.7 has
    > + /* ... but give the TSC a fair chance */
    > + if (lost_count > 25)
    > + cpufreq_delayed_get();
    > While looking at porting this code to x86-64 I noticed that this only runs for
    > the first lost timer event.

    Not exactly: lost_count is increased for every "tick" where lost ticks are
    detected, but re-set anytime there is no lost tick.

    > In case of dynamic frequency which varies shouldn't this
    > be more like
    > if ((lost_count % 25) == 0)
    > cpufreq_delayed_get();
    > ? Otherwise this heuristic will only work once.

    So if this heuristic works, no more ticks will be lost (at least in the near
    future), so lost_count will be set to zero again. If, due to some new event,
    ticks are lost again, lost_count will start at zero, reach 25 after some
    time, and cpufreq_delayed_get() will be called again.

    However: inaccuracies are only detected in _one_ direction: ticks being
    missed, not "too many ticks" -- and only if it's a factor of two or
    higher... Probably a better run-time check of the sanity of a timesource is
    needed in future... on the other hand, frequencies shouldn't change behind
    the kernel's back. That's what my other patch sent to the ACPI list a few
    days ago (pstate_cnt) tries to address.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.020 / U:21.756 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site