linux.git/kernel/sched_clock.c, branch v2.6.27-rc4

sched_clock: delay using sched_clock()

2008-08-11T06:59:03+00:00

Some arch's can't handle sched_clock() being called too early - delay
this until sched_clock_init() has been called.

Reported-by: Bill Gatliff 
Signed-off-by: Peter Zijlstra 
Tested-by: Nishanth Aravamudan 
CC: Russell King - ARM Linux 
Signed-off-by: Ingo Molnar

sched clock: couple local and remote clocks

2008-07-31T15:21:01+00:00

When taking the time of a remote CPU, use the opportunity to
couple (sync) the clocks to each other. (in a monotonic way)

Signed-off-by: Ingo Molnar 
Acked-by: Peter Zijlstra 
Acked-by: Mike Galbraith

sched clock: simplify __update_sched_clock()

2008-07-31T15:20:55+00:00

- return the current clock instead of letting callers
  fetch it from scd->clock

Signed-off-by: Ingo Molnar 
Acked-by: Peter Zijlstra 
Acked-by: Mike Galbraith

sched: eliminate scd->prev_raw

2008-07-31T15:20:49+00:00

eliminate prev_raw and use tick_raw instead.

It's enough to base the current time on the scheduler tick timestamp
alone - the monotonicity and maximum checks will prevent any damage.

Signed-off-by: Ingo Molnar 
Acked-by: Peter Zijlstra 
Acked-by: Mike Galbraith

sched clock: clean up sched_clock_cpu()

2008-07-31T15:20:42+00:00

- simplify the remote clock rebasing

Signed-off-by: Ingo Molnar 
Acked-by: Peter Zijlstra 
Acked-by: Mike Galbraith

sched clock: revert various sched_clock() changes

2008-07-31T15:20:29+00:00

Found an interactivity problem on a quad core test-system - simple
CPU loops would occasionally delay the system un an unacceptable way.

After much debugging with Peter Zijlstra it turned out that the problem
is caused by the string of sched_clock() changes - they caused the CPU
clock to jump backwards a bit - which confuses the scheduler arithmetics.

(which is unsigned for performance reasons)

So revert:

 # c300ba2: sched_clock: and multiplier for TSC to gtod drift
 # c0c8773: sched_clock: only update deltas with local reads.
 # af52a90: sched_clock: stop maximum check on NO HZ
 # f7cce27: sched_clock: widen the max and min time

This solves the interactivity problems.

Signed-off-by: Ingo Molnar 
Acked-by: Peter Zijlstra 
Acked-by: Mike Galbraith

sched: move sched_clock before first use

2008-07-28T14:35:03+00:00

Move sched_clock() up to stop warning: weak declaration of `sched_clock'
after first use results in unspecified behavior (if -fno-unit-at-a-time).

Signed-off-by: Hugh Dickins 
Cc: Mike Travis 
Cc: Ben Herrenschmidt 
Cc: Linuxppc-dev@ozlabs.org
Signed-off-by: Ingo Molnar

Merge branch 'sched/clock' into sched/devel

2008-07-14T10:19:13+00:00

sched_clock: and multiplier for TSC to gtod drift

2008-07-11T13:53:28+00:00

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 
Cc: Steven Rostedt 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: john stultz 
Signed-off-by: Ingo Molnar

sched_clock: record TSC after gtod

2008-07-11T13:53:27+00:00

To read the gtod we need to grab the xtime lock for read. Reading the gtod
before the TSC can cause a bigger gab if the xtime lock is contended.

This patch simply reverses the order to read the TSC after the gtod.
The locking in the reading of the gtod handles any barriers one might
think is needed.

Signed-off-by: Steven Rostedt 
Cc: Steven Rostedt 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: john stultz 
Signed-off-by: Ingo Molnar