From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Luis Vazquez Cao Subject: Re: Monotonic clock with KVM pv-clock Date: Tue, 21 Jan 2014 23:23:37 +0900 Message-ID: <52DE82E9.8010205@lab.ntt.co.jp> References: <20140120095656.GA1282@fermat.math.technion.ac.il> <20140120133317.GA7509@amt.cnet> <52DD39DB.3040109@lab.ntt.co.jp> <20140121001945.GA32105@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Nadav Har'El" , kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from tama500.ecl.ntt.co.jp ([129.60.39.148]:52758 "EHLO tama500.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754053AbaAUOXz (ORCPT ); Tue, 21 Jan 2014 09:23:55 -0500 In-Reply-To: <20140121001945.GA32105@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: (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. 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) 4. The timestamp returned is in nanoseconds. Besides, for sched_clock() to be considered stable 5. it has to be synchronized across CPUs. > (kvmclock_read can be nondecreasing due to TSC->nanosecond scaling, s/nondecreasing/nonincreasing/? 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. > 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. I think that when PVCLOCK_TSC_STABLE_BIT is set we should be fine as long as backward motion is filtered out.