Definition of sched_clock broken

[Jeremy Fitzhardinge <jeremy@goop.org>]

kernel/sched_clock.c has the comment:

 * The clock: sched_clock_cpu() is monotonic per cpu, and should be somewhat
 * consistent between cpus (never more than 2 jiffies difference).


The two jiffy restriction is way too restrictive.

Historically sched_clock() is intended to measure the amount of
schedulable time occurring on a CPU.  On a virtual cpu, that is affected
by the amount of physical cpu time the hypervisor schedules for a vcpu,
and can therefore advance in a very non-continuous way, depending on the
overall load on the host system.  It is, however, the only timebase that
gives the kernel a reasonable hope of determining how much cpu a process
actually got scheduled.

The net result is that the sched_clock timebase is 1) monotonic, 2)
loses arbitrary amounts of time against a system monotonic clock, 3)
per-cpu, with 4) arbitrary drift between different cpu's sched_clocks.

Tying the sched_clocks of different cpus together in any way loses these
properties, and just turns it into another system wide monotonic clock,
which seems redundant given that we already have one (I understand that
the relatively loose synchronization allows it to be implemented more
efficiently than a normal monotonic clock).

At the moment the x86 sched_clock is hooked through paravirt_ops so that
the underlying hypervisor can provide precise scheduled time
information, with the hope that the scheduler will use it to make better
decisions.  However if the scheduler needs to be lied to then I can do
that too, but it's a pity to throw away information that's available to it.

    J