]> pilppa.com Git - linux-2.6-omap-h63xx.git/commit
sched_clock: and multiplier for TSC to gtod drift
authorSteven Rostedt <rostedt@goodmis.org>
Wed, 9 Jul 2008 04:15:33 +0000 (00:15 -0400)
committerIngo Molnar <mingo@elte.hu>
Fri, 11 Jul 2008 13:53:28 +0000 (15:53 +0200)
commitc300ba252829e9325e08f0af60687add94445b25
tree93c583012a3f26617e95aea516c02716ce254f5d
parenta83bc47c33ab182f1e48977fd5a04024d713c75e
sched_clock: and multiplier for TSC to gtod drift

The sched_clock code currently tries to keep all CPU clocks of all CPUS
somewhat in sync. At every clock tick it records the gtod clock and
uses that and jiffies and the TSC to calculate a CPU clock that tries to
stay in sync with all the other CPUs.

ftrace depends heavily on this timer and it detects when this timer
"jumps".  One problem is that the TSC and the gtod also drift.
When the TSC is 0.1% faster or slower than the gtod it is very noticeable
in ftrace. To help compensate for this, I've added a multiplier that
tries to keep the CPU clock updating at the same rate as the gtod.

I've tried various ways to get it to be in sync and this ended up being
the most reliable. At every scheduler tick we calculate the new multiplier:

  multi = delta_gtod / delta_TSC

This means we perform a 64 bit divide at the tick (once a HZ). A shift
is used to handle the accuracy.

Other methods that failed due to dynamic HZ are:

(not used)  multi += (gtod - tsc) / delta_gtod
(not used)  multi += (gtod - (last_tsc + delta_tsc)) / delta_gtod

as well as other variants.

This code still allows for a slight drift between TSC and gtod, but
it keeps the damage down to a minimum.

Signed-off-by: Steven Rostedt <srostedt@redhat.com>
Cc: Steven Rostedt <srostedt@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: john stultz <johnstul@us.ibm.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
kernel/sched_clock.c