On Tue, Jan 21, 2014 at 11:23:37PM +0900, Fernando Luis Vazquez Cao wrote: > (2014/01/21 9:19), Marcelo Tosatti wrote: > >On Mon, Jan 20, 2014 at 11:59:39PM +0900, Fernando Luis Vazquez Cao wrote: > >>(2014/01/20 22:33), Marcelo Tosatti wrote: > >>>On Mon, Jan 20, 2014 at 11:56:56AM +0200, Nadav Har'El wrote: > >>>>If KVM_SYSTEM_TIME is not a correct way to get a monotonic paravirtual clock > >>>>from KVM, is there a correct way? > >>>Inside a Linux guest? Can use sched_clock(). > >>I would like to mention that Linux guests usually do not use sched_clock() > >>directly. The reason being that the kvm_clock based sched_clock() is not > >>marked stable (sched_clock_stable is 0), which means that the pair of > >>wrappers sched_clock_local()/sched_clock_remote() is used instead. > >Should verify the requirements of sched_clock_cpu() and enable > >sched_clock_stable in case it fulfills requirements > > The requirements of cpu_clock() are (from code comments in > kernel/sched/clock.c): > > 1. cpu_clock(i) provides a fast (execution time) high resolution > 2. Clock with bounded drift between CPUs. How high of a resolution ? Or what is the effect of lowering resolution? > 3. The value of cpu_clock(i) is monotonic for constant i (when > comparing cpu_clock(i) > to cpu_clock(j) for i != j, time can go backwards) OK. > 4. The timestamp returned is in nanoseconds. OK. > Besides, for sched_clock() to be considered stable > > 5. it has to be synchronized across CPUs. This contradicts item 3 ? > >(kvmclock_read can be nondecreasing due to TSC->nanosecond scaling, > > s/nondecreasing/nonincreasing/? Yes. > I guess you mean that consecutive calls to > kvm_clock_read() can return the same nanosecond value when the TSC > frequency is greater than 1GHz or there are frequency changes. Yes, when CPU can execute more than one kvm_clock_read's in one nanosecond. > >and not increase for a longer duration with global accumulator, due > >to cmpxchg) > > Yes. If I understand correctly, that can happen if > PVCLOCK_TSC_STABLE_BIT is not set. Yes. > I think that when PVCLOCK_TSC_STABLE_BIT is set we should be fine as > long as backward motion is filtered out. There can be no backward motion with PVCLOCK_TSC_STABLE_BIT (in theory, and no reports have been seen yet). Do you have any numbers for the change? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
