From: Zhanghailiang <zhang.zhanghailiang@huawei.com>
To: "Zhang, Chen" <chen.zhang@intel.com>
Cc: Jason Wang <jasowang@redhat.com>,
Lukas Straub <lukasstraub2@web.de>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
Li Zhijian <lizhijian@cn.fujitsu.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: RE: About migration/colo issue
Date: Fri, 15 May 2020 08:05:21 +0000 [thread overview]
Message-ID: <c5381e8bae0142618a9f4e9d7d7421bf@huawei.com> (raw)
In-Reply-To: <20200515091208.40817d99@luklap>
Hi,
I can't reproduce this issue with the qemu upstream either,
It works well.
Did you use an old version ?
Thanks,
Hailiang
> -----Original Message-----
> From: Lukas Straub [mailto:lukasstraub2@web.de]
> Sent: Friday, May 15, 2020 3:12 PM
> To: Zhang, Chen <chen.zhang@intel.com>
> Cc: Zhanghailiang <zhang.zhanghailiang@huawei.com>; Dr . David Alan
> Gilbert <dgilbert@redhat.com>; qemu-devel <qemu-devel@nongnu.org>; Li
> Zhijian <lizhijian@cn.fujitsu.com>; Jason Wang <jasowang@redhat.com>
> Subject: Re: About migration/colo issue
>
> On Fri, 15 May 2020 03:16:18 +0000
> "Zhang, Chen" <chen.zhang@intel.com> wrote:
>
> > Hi Hailiang/Dave.
> >
> > I found a urgent problem in current upstream code, COLO will stuck on
> secondary checkpoint and later.
> > The guest will stuck by this issue.
> > I have bisect upstream code, this issue caused by Hailiang's optimize patch:
>
> Hmm, I'm on v5.0.0 (where that commit is in) and I don't have this issue in
> my testing.
>
> Regards,
> Lukas Straub
>
> > From 0393031a16735835a441b6d6e0495a1bd14adb90 Mon Sep 17
> 00:00:00 2001
> > From: zhanghailiang <zhang.zhanghailiang@huawei.com>
> > Date: Mon, 24 Feb 2020 14:54:10 +0800
> > Subject: [PATCH] COLO: Optimize memory back-up process
> >
> > This patch will reduce the downtime of VM for the initial process,
> > Previously, we copied all these memory in preparing stage of COLO
> > while we need to stop VM, which is a time-consuming process.
> > Here we optimize it by a trick, back-up every page while in migration
> > process while COLO is enabled, though it affects the speed of the
> > migration, but it obviously reduce the downtime of back-up all SVM'S
> > memory in COLO preparing stage.
> >
> > Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
> > Message-Id:
> <20200224065414.36524-5-zhang.zhanghailiang@huawei.com>
> > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > minor typo fixes
> >
> > Hailiang, do you have time to look into it?
> >
> > ...
prev parent reply other threads:[~2020-05-15 8:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 3:16 About migration/colo issue Zhang, Chen
2020-05-15 3:28 ` Zhanghailiang
2020-05-15 3:32 ` Zhang, Chen
2020-05-15 7:12 ` Lukas Straub
2020-05-15 8:05 ` Zhanghailiang [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=c5381e8bae0142618a9f4e9d7d7421bf@huawei.com \
--to=zhang.zhanghailiang@huawei.com \
--cc=chen.zhang@intel.com \
--cc=dgilbert@redhat.com \
--cc=jasowang@redhat.com \
--cc=lizhijian@cn.fujitsu.com \
--cc=lukasstraub2@web.de \
--cc=qemu-devel@nongnu.org \
/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.