From: Avi Kivity <avi@redhat.com>
To: Zachary Amsden <zamsden@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Glauber Costa <glommer@redhat.com>,
Jeremy Fitzhardinge <jeremy@goop.org>,
kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] Add a global synchronization point for pvclock
Date: Wed, 21 Apr 2010 11:06:06 +0300 [thread overview]
Message-ID: <4BCEB1EE.9050002@redhat.com> (raw)
In-Reply-To: <4BCE403E.7050605@redhat.com>
On 04/21/2010 03:01 AM, Zachary Amsden wrote:
>>> on this machine Glauber mentioned, or even on a multi-core Core 2 Duo),
>>> but the delta calculation is very hard (if not impossible) to get
>>> right.
>>>
>>> The timewarps i've seen were in the 0-200ns range, and very rare (once
>>> every 10 minutes or so).
>>
>> Might be due to NMIs or SMIs interrupting the rdtsc(); ktime_get()
>> operation which establishes the timeline. We could limit it by
>> having a loop doing rdtsc(); ktime_get(); rdtsc(); and checking for
>> some bound, but it isn't worthwhile (and will break nested
>> virtualization for sure). Better to have the option to calibrate
>> kvmclock just once on machines with
>> X86_FEATURE_NONSTOP_TRULY_RELIABLE _TSC_HONESTLY.
> Yes. So its not as if the guest visible TSCs go out of sync (they don't
>
> There's a perfect way to do this and it still fails to stop
> timewarps. You can set the performance counters to overflow if more
> instructions are issued than your code path, run an assembly
> instruction stream and if the performance interrupt hits, restart the
> calibration.
It's completely impractical. The PMU is a global resource that is
already shared among users and the host; programming and restoring it is
expensive; and in a virtualized environment it the whole scheme may fail.
>
> The calibration happens not just once, but on every migration, and
> currently, I believe, on every VCPU switch. Even if we reduce the
> number of calibrations to the bare minimum and rule out SMIs and NMIs,
> there will still be variation due to factors beyond our control
> because of the unpredictable nature of cache and instruction issue.
Right.
>
> However, X86_FEATURE_NONSTOP_TRULY_RELIABLE_TSC_HONESTLY does imply
> one key feature which the code is missing today: on SMP VMs, the
> calibration of kvmclock needs to be done only once, and the clock can
> then be used for all VCPUs. That, I think, stops Glauber's bug from
> appearing on the server side.
That's the plan.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2010-04-21 8:06 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-15 18:37 [PATCH 0/5] pv clock misc fixes Glauber Costa
2010-04-15 18:37 ` [PATCH 1/5] Add a global synchronization point for pvclock Glauber Costa
2010-04-15 18:37 ` [PATCH 2/5] change msr numbers for kvmclock Glauber Costa
2010-04-15 18:37 ` [PATCH 3/5] Try using new kvm clock msrs Glauber Costa
2010-04-15 18:37 ` [PATCH 4/5] export new cpuid KVM_CAP Glauber Costa
2010-04-15 18:37 ` [PATCH 5/5] add documentation about kvmclock Glauber Costa
2010-04-15 19:28 ` Randy Dunlap
2010-04-15 20:10 ` Glauber Costa
2010-04-17 18:58 ` [PATCH 4/5] export new cpuid KVM_CAP Avi Kivity
2010-04-19 14:50 ` Glauber Costa
2010-04-20 9:29 ` Avi Kivity
2010-04-17 18:55 ` [PATCH 3/5] Try using new kvm clock msrs Avi Kivity
2010-04-17 18:51 ` [PATCH 2/5] change msr numbers for kvmclock Avi Kivity
2010-04-16 20:23 ` [PATCH 1/5] Add a global synchronization point for pvclock Marcelo Tosatti
2010-04-16 20:36 ` Jeremy Fitzhardinge
2010-04-16 21:05 ` Zachary Amsden
2010-04-19 10:39 ` Peter Zijlstra
2010-04-19 10:50 ` Avi Kivity
2010-04-19 11:05 ` Peter Zijlstra
2010-04-19 11:10 ` Avi Kivity
2010-04-19 14:21 ` Glauber Costa
2010-04-19 14:33 ` Avi Kivity
2010-04-19 14:46 ` Peter Zijlstra
2010-04-19 16:18 ` Jeremy Fitzhardinge
2010-04-20 9:31 ` Avi Kivity
2010-04-20 18:23 ` Jeremy Fitzhardinge
2010-04-20 18:54 ` Avi Kivity
2010-04-20 19:42 ` Jeremy Fitzhardinge
2010-04-21 0:07 ` Zachary Amsden
2010-04-22 13:11 ` Glauber Costa
2010-04-23 1:44 ` Zachary Amsden
2010-04-23 9:34 ` Avi Kivity
2010-04-23 19:22 ` Jeremy Fitzhardinge
2010-04-23 19:25 ` Avi Kivity
2010-04-23 21:31 ` Zachary Amsden
2010-04-23 21:35 ` Jeremy Fitzhardinge
2010-04-23 21:41 ` Zachary Amsden
2010-04-24 9:30 ` Avi Kivity
2010-04-24 9:29 ` Avi Kivity
2010-04-19 16:11 ` Jeremy Fitzhardinge
2010-04-19 14:26 ` Glauber Costa
2010-04-19 16:19 ` Jeremy Fitzhardinge
2010-04-19 18:25 ` Glauber Costa
2010-04-20 1:57 ` Marcelo Tosatti
2010-04-20 9:35 ` Avi Kivity
2010-04-20 12:59 ` Glauber Costa
2010-04-20 15:16 ` Avi Kivity
2010-04-21 0:01 ` Zachary Amsden
2010-04-21 8:06 ` Avi Kivity [this message]
2010-04-17 18:48 ` Avi Kivity
2010-04-17 18:49 ` Avi Kivity
2010-04-19 10:43 ` Peter Zijlstra
2010-04-19 10:47 ` Avi Kivity
2010-04-19 10:56 ` Peter Zijlstra
2010-04-19 11:13 ` Avi Kivity
2010-04-19 11:19 ` Peter Zijlstra
2010-04-19 11:40 ` Avi Kivity
2010-04-19 14:32 ` Glauber Costa
2010-04-19 14:37 ` Avi Kivity
2010-04-19 10:46 ` Peter Zijlstra
2010-04-19 10:49 ` Avi Kivity
2010-04-19 10:51 ` Peter Zijlstra
2010-04-19 10:54 ` Avi Kivity
2010-04-19 18:35 ` Zachary Amsden
2010-04-20 9:39 ` Avi Kivity
2010-04-21 0:05 ` Zachary Amsden
2010-04-21 8:08 ` Avi Kivity
2010-04-19 10:49 ` Peter Zijlstra
2010-04-19 10:53 ` Avi Kivity
2010-04-19 10:59 ` Peter Zijlstra
2010-04-19 11:35 ` Avi Kivity
2010-10-25 23:30 ` Jeremy Fitzhardinge
2010-10-26 8:14 ` Avi Kivity
2010-10-26 10:49 ` Glauber Costa
2010-10-26 17:04 ` Jeremy Fitzhardinge
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BCEB1EE.9050002@redhat.com \
--to=avi@redhat.com \
--cc=glommer@redhat.com \
--cc=jeremy@goop.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=zamsden@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox