All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Glauber Costa <glommer@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	aliguori@us.ibm.com, Rik van Riel <riel@redhat.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 2/6] KVM-HV: KVM Steal time implementation
Date: Tue, 01 Feb 2011 19:09:23 +0200	[thread overview]
Message-ID: <4D483E43.5060904@redhat.com> (raw)
In-Reply-To: <1296575320.5081.8.camel@mothafucka.localdomain>

On 02/01/2011 05:48 PM, Glauber Costa wrote:
> >  >  @@ -2106,6 +2120,25 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> >  >    			kvm_migrate_timers(vcpu);
> >  >    		vcpu->cpu = cpu;
> >  >    	}
> >  >  +
> >  >  +	if (vcpu->arch.this_time_out) {
> >  >  +		u64 to = (get_kernel_ns() - vcpu->arch.this_time_out);
> >  >  +		/*
> >  >  +		 * using nanoseconds introduces noise, which accumulates easily
> >  >  +		 * leading to big steal time values. We want, however, to keep the
> >  >  +		 * interface nanosecond-based for future-proofness.
> >  >  +		 */
> >  >  +		to /= NSEC_PER_USEC;
> >  >  +		to *= NSEC_PER_USEC;
> >
> >  Seems there is a real problem and that this is just papering it over.
> >  I'd like to understand the root cause.
> Okay, my self-explanation seemed reasonable to me, but since both you
> and Peter dislike it, I think it is important enough to get a more
> thorough investigation before a second round.

Yes please.

> But in this case,
> I keep that using nanoseconds may then not be the best approach here. We
> also have to keep in mind that the host and guest clocks may be running
> at different resolutions.

We need to choose a resolution for the clock (or negotiate one), an 
nanoseconds seems as good as any from a range and precision 
considerations, and is convenient for the host and Linux guests.  So why 
not pick it?

> >  >  +		vcpu->arch.sversion += 2;
> >
> >  Doesn't survive live migration.  You need to use the version from the
> >  guest area.
> Why not? Who said versions need to always increase? If current version
> is 102324, and we live migrate and it becomes 0, what is the problem?

Guest reads version (result: 2)
Guest starts reading data
Live migration; vcpu->arch.sversion is zeroed
Steal time update; vcpu->arch.sversion += 2; write to guest
Guest continues reading data
Guest reads version (result: 2)

So the guest is unaware that an update has occurred while it was reading 
the data.

-- 
error compiling committee.c: too many arguments to function


  reply	other threads:[~2011-02-01 17:09 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-28 19:52 [PATCH v2 0/6] KVM Steal time, new submission Glauber Costa
2011-01-28 19:52 ` [PATCH v2 1/6] KVM-HDR: KVM Steal time implementation Glauber Costa
2011-01-29  1:28   ` Rik van Riel
2011-01-28 19:52 ` [PATCH v2 2/6] KVM-HV: " Glauber Costa
2011-01-29  1:46   ` Rik van Riel
2011-01-30 13:13   ` Avi Kivity
2011-02-01 15:48     ` Glauber Costa
2011-02-01 17:09       ` Avi Kivity [this message]
2011-02-01 19:58         ` Glauber Costa
2011-02-02 10:09           ` Avi Kivity
2011-01-31 11:07   ` Peter Zijlstra
2011-01-28 19:52 ` [PATCH v2 3/6] KVM-GST: KVM Steal time accounting Glauber Costa
2011-01-29  1:16   ` Jeremy Fitzhardinge
2011-01-29  1:27     ` Glauber Costa
2011-01-29  1:53   ` Rik van Riel
2011-01-30 14:04   ` Avi Kivity
2011-01-30 16:45     ` lidong chen
2011-02-01 15:58       ` Glauber Costa
2011-02-01 15:57     ` Glauber Costa
2011-02-02 10:11       ` Avi Kivity
2011-02-02 10:51         ` Avi Kivity
2011-02-02 11:57           ` Glauber Costa
2011-01-28 19:52 ` [PATCH v2 4/6] KVM-GST: KVM Steal time registration Glauber Costa
2011-01-29  2:16   ` Rik van Riel
2011-01-30 13:16   ` Avi Kivity
2011-02-01 15:53     ` Glauber Costa
2011-02-01 16:17       ` Peter Zijlstra
2011-02-01 17:00         ` Glauber Costa
2011-02-01 17:44           ` Peter Zijlstra
2011-02-01 20:20             ` Venkatesh Pallipadi
2011-01-31 11:11   ` Peter Zijlstra
2011-01-28 19:52 ` [PATCH v2 5/6] KVM-GST: adjust scheduler cpu power Glauber Costa
2011-01-31 11:25   ` Peter Zijlstra
2011-01-31 11:27     ` Peter Zijlstra
2011-02-01 15:59     ` Glauber Costa
2011-02-01 16:19       ` Peter Zijlstra
2011-02-01 16:22         ` Glauber Costa
2011-02-01 18:59           ` Peter Zijlstra
2011-02-01 19:55             ` Glauber Costa
2011-02-01 20:04               ` Peter Zijlstra
2011-01-28 19:52 ` [PATCH v2 6/6] Describe KVM_MSR_STEAL_TIME Glauber Costa
2011-01-30 13:19   ` Avi Kivity
2011-02-01 15:54     ` Glauber Costa
2011-02-02 10:14       ` Avi Kivity

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=4D483E43.5060904@redhat.com \
    --to=avi@redhat.com \
    --cc=aliguori@us.ibm.com \
    --cc=glommer@redhat.com \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.