qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Jitendra Kolhe <jitendra.kolhe@hpe.com>
To: Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org
Cc: JBottomley@Odin.com, ehabkost@redhat.com,
	crosthwaite.peter@gmail.com, simhan@hpe.com, quintela@redhat.com,
	armbru@redhat.com, lcapitulino@redhat.com,
	borntraeger@de.ibm.com, mst@redhat.com,
	mohan_parthasarathy@hpe.com, stefanha@redhat.com, den@openvz.org,
	amit.shah@redhat.com, pbonzini@redhat.com, dgilbert@redhat.com,
	rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v2] migration: skip sending ram pages released by virtio-balloon driver.
Date: Tue, 29 Mar 2016 17:43:09 +0530	[thread overview]
Message-ID: <56FA7155.6050700@hpe.com> (raw)
In-Reply-To: <56F93B80.8090803@redhat.com>

On 3/28/2016 7:41 PM, Eric Blake wrote:
> On 03/27/2016 10:16 PM, Jitendra Kolhe wrote:
>> While measuring live migration performance for qemu/kvm guest, it
>> was observed that the qemu doesn’t maintain any intelligence for the
>> guest ram pages which are released by the guest balloon driver and
>> treat such pages as any other normal guest ram pages. This has direct
>> impact on overall migration time for the guest which has released
>> (ballooned out) memory to the host.
>>
>> In case of large systems, where we can configure large guests with 1TB
>> and with considerable amount of memory release by balloon driver to the,
>> host the migration time gets worse.
> 
> s/the, host/the host,/
> 
>>
>> The optimization gets temporarily disabled, if the balloon operation is
> 
> s/disabled,/disabled/
> 
>> in progress. Since the optimization skips scanning and migrating control
>> information for ballooned out pages, we might skip guest ram pages in
>> cases where the guest balloon driver has freed the ram page to the guest
>> but not yet informed the host/qemu about the ram page
>> (VIRTIO_BALLOON_F_MUST_TELL_HOST). In such case with optimization, we
>> might skip migrating ram pages which the guest is using. Since this
>> problem is specific to balloon leak, we can restrict balloon operation in
>> progress check to only balloon leak operation in progress check.
>>
>> The optimization also get permanently disabled (for all subsequent
> 
> s/get/gets/
> 
>> migrations) in case any of the migration uses postcopy capability. In case
>> of postcopy the balloon bitmap would be required to send after vm_stop,
>> which has significant impact on the downtime. Moreover, the applications
>> in the guest space won’t be actually faulting on the ram pages which are
>> already ballooned out, the proposed optimization will not show any
>> improvement in migration time during postcopy.
>>
>> Signed-off-by: Jitendra Kolhe <jitendra.kolhe@hpe.com>
>> ---
>> Changed in v2:
>>  - Resolved compilation issue for qemu-user binaries in exec.c
>>  - Localize balloon bitmap test to save_zero_page().
>>  - Updated version string for newly added migration capability to 2.7.
>>  - Made minor modifications to patch commit text.
> 
> I'll leave the technical review to others.
> 
>> +++ b/qapi-schema.json
>> @@ -544,11 +544,14 @@
>>  #          been migrated, pulling the remaining pages along as needed. NOTE: If
>>  #          the migration fails during postcopy the VM will fail.  (since 2.6)
>>  #
>> +# @skip-balloon: Skip scanning ram pages released by virtio-balloon driver.
>> +#          (since 2.7)
>> +#
>>  # Since: 1.2
>>  ##
>>  { 'enum': 'MigrationCapability',
>>    'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
>> -           'compress', 'events', 'postcopy-ram'] }
>> +           'compress', 'events', 'postcopy-ram', 'skip-balloon'] }
> 
> Does this flag make sense to always have enabled (in which case we don't
> need it as a flag), or are there cases where we'd explicitly want to
> disable it?
> 

Yes the flag can be enabled for most of the time, except in cases 
like migration using postcopy-ram (mutually exclusive) or in cases 
where the user is confident that the optimization is of no benefit 
(for e.g. no or very less pct of balloon activity has happened on 
VM i.e. penalty vs gain).

Thanks,
- Jitendra

  reply	other threads:[~2016-03-29 12:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-28  4:16 [Qemu-devel] [PATCH v2] migration: skip sending ram pages released by virtio-balloon driver Jitendra Kolhe
2016-03-28  6:59 ` Michael S. Tsirkin
2016-03-29 10:05   ` Paolo Bonzini
2016-03-29 10:47     ` Jitendra Kolhe
2016-03-29 10:48       ` Paolo Bonzini
2016-04-01 11:19         ` Jitendra Kolhe
2016-03-28 10:36 ` Denis V. Lunev
2016-03-29 11:34   ` Jitendra Kolhe
2016-03-28 14:11 ` Eric Blake
2016-03-29 12:13   ` Jitendra Kolhe [this message]
2016-03-29 12:28 ` Michael S. Tsirkin
2016-04-01 11:08   ` Jitendra Kolhe
2016-04-10 16:59     ` Michael S. Tsirkin
2016-04-13 10:54       ` Jitendra Kolhe
2016-04-13 11:10         ` Michael S. Tsirkin
2016-04-13 11:15           ` Dr. David Alan Gilbert
2016-04-13 11:36             ` Michael S. Tsirkin
2016-04-29 10:31               ` Jitendra Kolhe
2016-03-31 16:39 ` Dr. David Alan Gilbert
2016-04-05 10:04   ` Jitendra Kolhe

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=56FA7155.6050700@hpe.com \
    --to=jitendra.kolhe@hpe.com \
    --cc=JBottomley@Odin.com \
    --cc=amit.shah@redhat.com \
    --cc=armbru@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=den@openvz.org \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=mohan_parthasarathy@hpe.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    --cc=rth@twiddle.net \
    --cc=simhan@hpe.com \
    --cc=stefanha@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;
as well as URLs for NNTP newsgroup(s).