lost timer check in 2.6.7
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. 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.
-Andi
Quoted 9 lines · Andi Kleen
2.6.7 has
(quoted diff) +3
-0+ /* ... 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.
Quoted 7 lines
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.
Dominik