From: Peter Xu <peterx@redhat.com>
To: Balamuruhan S <bala24@linux.vnet.ibm.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: qemu-devel@nongnu.org, amit.shah@redhat.com, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH] migration: calculate expected_downtime with ram_bytes_remaining()
Date: Wed, 4 Apr 2018 16:06:00 +0800 [thread overview]
Message-ID: <20180404080600.GA10540@xz-mi> (raw)
In-Reply-To: <bb088a1ba2e344273db32402f7c9fae4@linux.vnet.ibm.com>
On Wed, Apr 04, 2018 at 11:55:14AM +0530, Balamuruhan S wrote:
[...]
> > too. So still I'll put aside the "which one is better" question.
> >
> > For your use case, you can have a look on either of below way to
> > have a converged migration:
> >
> > - auto-converge: that's a migration capability that throttles CPU
> > usage of guests
>
> I used auto-converge option before hand and still it doesn't help
> for migration to complete
Have you digged about why? AFAIK auto-convergence will at last absort
merely the whole vcpu resource (99% of them maximum). Maybe you are
not with the best throttle values? Or do you think that could be a
auto-convergence bug too?
>
> >
> > - postcopy: that'll let you start the destination VM even without
> > transferring all the RAMs before hand
>
> I am seeing issue in postcopy migration between POWER8(16M) -> POWER9(1G)
> where the hugepage size is different. I am trying to enable it but host
> start
> address have to be aligned with 1G page size in ram_block_discard_range(),
> which I am debugging further to fix it.
I thought the huge page size needs to be matched on both side
currently for postcopy but I'm not sure. CC Dave (though I think
Dave's still on PTO).
--
Peter Xu
next prev parent reply other threads:[~2018-04-04 8:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-04 6:25 [Qemu-devel] [PATCH] migration: calculate expected_downtime with ram_bytes_remaining() Balamuruhan S
2018-04-04 8:06 ` Peter Xu [this message]
2018-04-04 8:49 ` Balamuruhan S
2018-04-09 18:57 ` Dr. David Alan Gilbert
2018-04-10 1:22 ` David Gibson
2018-04-10 10:02 ` Dr. David Alan Gilbert
2018-04-11 1:28 ` David Gibson
-- strict thread matches above, loose matches on Subject: below --
2018-03-31 18:55 Balamuruhan S
2018-04-03 6:10 ` Peter Xu
2018-04-03 17:30 ` bala24
2018-04-04 1:59 ` Peter Xu
2018-04-04 9:02 ` Juan Quintela
2018-04-04 9:04 ` Juan Quintela
2018-04-10 9:52 ` Balamuruhan S
2018-04-10 10:52 ` Balamuruhan S
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=20180404080600.GA10540@xz-mi \
--to=peterx@redhat.com \
--cc=amit.shah@redhat.com \
--cc=bala24@linux.vnet.ibm.com \
--cc=dgilbert@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@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.