All of lore.kernel.org
 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 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.