All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: "Shribman, Aidan" <aidan.shribman@sap.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Isaku Yamahata <yamahata@valinux.co.jp>
Subject: Re: [Qemu-devel] [PATCH] Add warmup phase for live migration of large memory apps
Date: Thu, 12 May 2011 12:39:22 +0200	[thread overview]
Message-ID: <m3k4dwkxt1.fsf@neno.mitica> (raw)
In-Reply-To: <AB5A8C7661872E428D6B8E1C2DFA35085CAAEEB246@DEWDFECCR02.wdf.sap.corp> (Aidan Shribman's message of "Thu, 12 May 2011 10:42:32 +0200")

"Shribman, Aidan" <aidan.shribman@sap.com> wrote:
>> On Wed, May 11, 2011 at 8:58 AM, Shribman, Aidan 
>> <aidan.shribman@sap.com> wrote:
>> > From: Aidan Shribman <aidan.shribman@sap.com>
>> >
>> > [PATCH] Add warmup phase for live migration of large memory apps
>> >
>> > By invoking "migrate -w <url>" we initiate a background 
>> live-migration
>> > transferring of dirty pages continuously until invocation 
>> of "migrate_end"
>> > which attempts to complete the live migration operation.
>> 
>> What is the purpose of this patch?  How and when do I use it?
>> 
>
> The warmup patch adds none-converging background update of guest
> memory during live-migration such that on request of live-migration
> completion (via "migrate_end" command) we get much faster
> response. This is especially needed when running a payload of large
> enterprise applications which have high memory demands.

We should integrate this with Kemari (Kemari is doing something like
this, just that it has more requirements).  Isaku, do you have any comments?

BTW, what loads have you tested for this?

if I setup an image with 1GB RAM and a DVD iso image, and do in the
guest:

while true; do find /media/cdrom -type f | xargs md5sum; done

Migration never converges with current code (if you use more than 1GB
memory, then all the DVD will be cached inside).

So, I see this only useful for guests that are almost idle, and on that
case, migration speed is not the bigger of your problems, no?

Later, Juan.

  reply	other threads:[~2011-05-12 10:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-11  7:58 [Qemu-devel] [PATCH] Add warmup phase for live migration of large memory apps Shribman, Aidan
2011-05-11  9:19 ` Stefan Hajnoczi
2011-05-12  8:42   ` Shribman, Aidan
2011-05-12 10:39     ` Juan Quintela [this message]
2011-05-12 10:54       ` Isaku Yamahata
2011-05-13  2:55         ` Yoshiaki Tamura
2011-05-15 14:25           ` Shribman, Aidan
2011-05-11 13:35 ` Anthony Liguori
2011-05-11 14:23   ` Shribman, Aidan
2011-05-12 10:57     ` Juan Quintela
2011-05-12 11:23       ` Shribman, Aidan
2011-05-12 13:12         ` Anthony Liguori
2011-05-12 10:55 ` Juan Quintela

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=m3k4dwkxt1.fsf@neno.mitica \
    --to=quintela@redhat.com \
    --cc=aidan.shribman@sap.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=yamahata@valinux.co.jp \
    /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.