qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Amit Shah <amit.shah@redhat.com>
To: Liang Li <liang.z.li@intel.com>
Cc: yong.y.wang@intel.com, pbonzini@redhat.com,
	qemu-devel@nongnu.org, stefanha@redhat.com, quintela@redhat.com
Subject: Re: [Qemu-devel] [v2 RESEND 0/4] Fix long vm downtime during live migration
Date: Tue, 3 Nov 2015 17:53:06 +0530	[thread overview]
Message-ID: <20151103122306.GI7673@grmbl.mre> (raw)
In-Reply-To: <1446449823-25049-1-git-send-email-liang.z.li@intel.com>

On (Mon) 02 Nov 2015 [15:36:59], Liang Li wrote:
> The patch 3ea3b7fa9af067982f34b of kvm introduces a lazy collapsing
> of small sptes into large sptes mechanism, which intend to solve the
> performance drop issue if live migration fails or is canceled. The
> rmap will be scanned in the KVM_SET_USER_MEMORY_REGION ioctl context
> when dirty logging is stopped so as to drop the small sptes, scanning
> the rmap and drop the small sptes is a time consuming operation which
> will take dozens of milliseconds, the actual time depends on VM's
> memory size. For a VM with 8GB RAM, it will take about 30ms.
> 
> The current QEMU code stop the dirty logging during the pause and
> copy stage by calling the migration_end() function. Now migration_end()
> is a time consuming operation because it calls
> memroy_global_dirty_log_stop(), which will trigger the scanning of rmap
> and dropping small sptes operation. So call migration_end() before all
> the vmsate data has already been transferred to the destination will
> prolong VM downtime.
> 
> migration_end() should be deferred after all the data has been
> transferred to the destination. blk_mig_cleanup() can be deferred too.

Reviewed-by: Amit Shah <amit.shah@redhat.com>

Thanks for adding to the commit message, that helped.


		Amit

      parent reply	other threads:[~2015-11-03 12:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-02  7:36 [Qemu-devel] [v2 RESEND 0/4] Fix long vm downtime during live migration Liang Li
2015-11-02  7:37 ` [Qemu-devel] [v2 RESEND 1/4] migration: defer migration_end & blk_mig_cleanup Liang Li
2015-11-03 12:28   ` Juan Quintela
2015-11-02  7:37 ` [Qemu-devel] [v2 RESEND 2/4] migration: rename qemu_savevm_state_cancel Liang Li
2015-11-03 12:29   ` Juan Quintela
2015-11-02  7:37 ` [Qemu-devel] [v2 RESEND 3/4] migration: rename cancel to cleanup in SaveVMHandles Liang Li
2015-11-03 12:30   ` Juan Quintela
2015-11-02  7:37 ` [Qemu-devel] [v2 RESEND 4/4] migration: code clean up Liang Li
2015-11-03 12:30   ` Juan Quintela
2015-11-02 11:54 ` [Qemu-devel] [v2 RESEND 0/4] Fix long vm downtime during live migration Paolo Bonzini
2015-11-03 12:36   ` Juan Quintela
2015-11-02 14:40 ` Stefan Hajnoczi
2015-11-03 12:23 ` Amit Shah [this message]

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=20151103122306.GI7673@grmbl.mre \
    --to=amit.shah@redhat.com \
    --cc=liang.z.li@intel.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=yong.y.wang@intel.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;
as well as URLs for NNTP newsgroup(s).