[lkml]   [2008]   [Sep]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectDefinition 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.


     \ /
      Last update: 2008-09-23 23:07    [W:0.021 / U:15.128 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site