Re: Monotonic clock with KVM pv-clock

From: Marcelo Tosatti <mtosatti@redhat.com>
To: Fernando Luis Vazquez Cao <fernando_b1@lab.ntt.co.jp>
Cc: "Nadav Har'El" <nyh@math.technion.ac.il>, kvm@vger.kernel.org
Subject: Re: Monotonic clock with KVM pv-clock
Date: Wed, 22 Jan 2014 13:41:16 -0200	[thread overview]
Message-ID: <20140122154116.GA23076@amt.cnet> (raw)
In-Reply-To: <52DE82E9.8010205@lab.ntt.co.jp>

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?