From: Marcelo Tosatti <mtosatti@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Radim Krcmar <rkrcmar@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
Date: Mon, 14 Nov 2016 13:37:35 -0200 [thread overview]
Message-ID: <20161114153733.GA31848@amt.cnet> (raw)
In-Reply-To: <874m3af905.fsf@emacs.mitica>
On Mon, Nov 14, 2016 at 03:09:46PM +0100, Juan Quintela wrote:
> Marcelo Tosatti <mtosatti@redhat.com> wrote:
> > Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which
> > indicates that KVM_GET_CLOCK returns a value as seen by the guest at
> > that moment.
> >
> > For new machine types, use this value rather than reading
> > from guest memory.
> >
> > This reduces kvmclock difference on migration from 5s to 0.1s
> > (when max_downtime == 5s).
> >
> > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>
> Acked-by: Juan Quintela <quintela@redhat.com>
>
> But, if you have to respin it ....
>
>
> > + /* whether machine supports reliable KVM_GET_CLOCK */
> > + bool mach_use_reliable_get_clock;
> > +
> > + /* whether source host supported reliable KVM_GET_CLOCK */
> > + bool src_use_reliable_get_clock;
>
> This two names are really long, but I don't have better suggesitons :-()
> > if (running) {
> > struct kvm_clock_data data = {};
> > - uint64_t time_at_migration = kvmclock_current_nsec(s);
> > + uint64_t time_at_migration = 0;
>
> This was not "time_at_migration", it was not already before, but just
> now it looks really weird. (as it was already faulty, this is why it is
> only a suggestion.)
>
> >
> > - s->clock_valid = false;
> > + /* local (running VM) restore */
> > + if (s->clock_valid) {
> > + /*
> > + * if host does not support reliable KVM_GET_CLOCK,
> > + * read kvmclock value from memory
> > + */
> > + if (!kvm_has_adjust_clock_stable()) {
> > + time_at_migration = kvmclock_current_nsec(s);
> > + }
> > + /* migration/savevm/init restore */
> > + } else {
> > + /*
> > + * use s->clock in case machine uses reliable
> > + * get clock and host where vm was executing
> > + * supported reliable get clock
> > + */
>
> This comment is just weird. Simplifying
> /* If A and B do C */
> if (!A and || !B) {
> then D();
> }
>
> Doing the opposite comment?
>
> Migration code looks rigth.
Fixed those.
> Once said that, I continue hating clocks.
Me too, especially the biological one.
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <mtosatti@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Radim Krcmar <rkrcmar@redhat.com>,
Eduardo Habkost <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
Date: Mon, 14 Nov 2016 13:37:35 -0200 [thread overview]
Message-ID: <20161114153733.GA31848@amt.cnet> (raw)
In-Reply-To: <874m3af905.fsf@emacs.mitica>
On Mon, Nov 14, 2016 at 03:09:46PM +0100, Juan Quintela wrote:
> Marcelo Tosatti <mtosatti@redhat.com> wrote:
> > Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which
> > indicates that KVM_GET_CLOCK returns a value as seen by the guest at
> > that moment.
> >
> > For new machine types, use this value rather than reading
> > from guest memory.
> >
> > This reduces kvmclock difference on migration from 5s to 0.1s
> > (when max_downtime == 5s).
> >
> > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
>
> Acked-by: Juan Quintela <quintela@redhat.com>
>
> But, if you have to respin it ....
>
>
> > + /* whether machine supports reliable KVM_GET_CLOCK */
> > + bool mach_use_reliable_get_clock;
> > +
> > + /* whether source host supported reliable KVM_GET_CLOCK */
> > + bool src_use_reliable_get_clock;
>
> This two names are really long, but I don't have better suggesitons :-()
> > if (running) {
> > struct kvm_clock_data data = {};
> > - uint64_t time_at_migration = kvmclock_current_nsec(s);
> > + uint64_t time_at_migration = 0;
>
> This was not "time_at_migration", it was not already before, but just
> now it looks really weird. (as it was already faulty, this is why it is
> only a suggestion.)
>
> >
> > - s->clock_valid = false;
> > + /* local (running VM) restore */
> > + if (s->clock_valid) {
> > + /*
> > + * if host does not support reliable KVM_GET_CLOCK,
> > + * read kvmclock value from memory
> > + */
> > + if (!kvm_has_adjust_clock_stable()) {
> > + time_at_migration = kvmclock_current_nsec(s);
> > + }
> > + /* migration/savevm/init restore */
> > + } else {
> > + /*
> > + * use s->clock in case machine uses reliable
> > + * get clock and host where vm was executing
> > + * supported reliable get clock
> > + */
>
> This comment is just weird. Simplifying
> /* If A and B do C */
> if (!A and || !B) {
> then D();
> }
>
> Doing the opposite comment?
>
> Migration code looks rigth.
Fixed those.
> Once said that, I continue hating clocks.
Me too, especially the biological one.
next prev parent reply other threads:[~2016-11-14 15:40 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-14 12:36 [qemu patch 0/2] improve kvmclock difference on migration Marcelo Tosatti
2016-11-14 12:36 ` [Qemu-devel] " Marcelo Tosatti
2016-11-14 12:36 ` [qemu patch 1/2] kvm: sync linux headers Marcelo Tosatti
2016-11-14 12:36 ` [Qemu-devel] " Marcelo Tosatti
2016-11-14 12:36 ` [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration Marcelo Tosatti
2016-11-14 12:36 ` [Qemu-devel] " Marcelo Tosatti
2016-11-14 13:54 ` Paolo Bonzini
2016-11-14 13:54 ` [Qemu-devel] " Paolo Bonzini
2016-11-14 14:00 ` Marcelo Tosatti
2016-11-14 14:00 ` [Qemu-devel] " Marcelo Tosatti
2016-11-14 14:22 ` Paolo Bonzini
2016-11-14 14:22 ` [Qemu-devel] " Paolo Bonzini
2016-11-14 14:50 ` Marcelo Tosatti
2016-11-14 14:50 ` [Qemu-devel] " Marcelo Tosatti
2016-11-14 15:00 ` Paolo Bonzini
2016-11-14 15:00 ` [Qemu-devel] " Paolo Bonzini
2016-11-14 15:40 ` Marcelo Tosatti
2016-11-14 15:40 ` [Qemu-devel] " Marcelo Tosatti
2016-11-14 16:43 ` Paolo Bonzini
2016-11-14 16:43 ` [Qemu-devel] " Paolo Bonzini
2016-11-14 17:13 ` Marcelo Tosatti
2016-11-14 17:13 ` [Qemu-devel] " Marcelo Tosatti
2016-11-14 17:20 ` Paolo Bonzini
2016-11-14 17:20 ` [Qemu-devel] " Paolo Bonzini
2016-11-14 18:15 ` Marcelo Tosatti
2016-11-14 18:15 ` [Qemu-devel] " Marcelo Tosatti
2016-11-17 12:16 ` Marcelo Tosatti
2016-11-17 12:16 ` [Qemu-devel] " Marcelo Tosatti
2016-11-17 13:03 ` Paolo Bonzini
2016-11-17 13:03 ` [Qemu-devel] " Paolo Bonzini
2016-11-28 13:47 ` Paolo Bonzini
2016-11-28 13:47 ` [Qemu-devel] " Paolo Bonzini
2016-11-28 14:28 ` Eduardo Habkost
2016-11-28 14:28 ` [Qemu-devel] " Eduardo Habkost
2016-11-28 15:12 ` Paolo Bonzini
2016-11-28 15:12 ` [Qemu-devel] " Paolo Bonzini
2016-11-28 16:36 ` Marcelo Tosatti
2016-11-28 16:36 ` [Qemu-devel] " Marcelo Tosatti
2016-11-28 17:30 ` Paolo Bonzini
2016-11-28 17:30 ` [Qemu-devel] " Paolo Bonzini
2016-11-14 14:11 ` Juan Quintela
2016-11-14 14:11 ` [Qemu-devel] " Juan Quintela
2016-11-14 14:09 ` Juan Quintela
2016-11-14 14:09 ` [Qemu-devel] " Juan Quintela
2016-11-14 15:37 ` Marcelo Tosatti [this message]
2016-11-14 15:37 ` Marcelo Tosatti
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=20161114153733.GA31848@amt.cnet \
--to=mtosatti@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rkrcmar@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.