Messages in this thread | | | Date | Tue, 23 Sep 2008 14:04:40 -0700 | From | Jeremy Fitzhardinge <> | Subject | Definition of sched_clock broken |
| |
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
| |