From: Wei Liu <wei.liu2@citrix.com>
To: Wen Congyang <wency@cn.fujitsu.com>
Cc: Lars Kurth <lars.kurth@citrix.com>,
Changlong Xie <xiecl.fnst@cn.fujitsu.com>,
Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <ian.campbell@citrix.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
Jiang Yunhong <yunhong.jiang@intel.com>,
Ian Jackson <ian.jackson@eu.citrix.com>,
xen devel <xen-devel@lists.xen.org>,
Dong Eddie <eddie.dong@intel.com>,
Gui Jianfeng <guijianfeng@cn.fujitsu.com>,
Shriram Rajagopalan <rshriram@cs.ubc.ca>,
Yang Hongyang <hongyang.yang@easystack.cn>
Subject: Re: [PATCH v7 12/18] tools/libx{l, c}: add back channel to libxc
Date: Wed, 3 Feb 2016 19:40:47 +0000 [thread overview]
Message-ID: <20160203194047.GB23178@citrix.com> (raw)
In-Reply-To: <1454045254-3711-13-git-send-email-wency@cn.fujitsu.com>
On Fri, Jan 29, 2016 at 01:27:28PM +0800, Wen Congyang wrote:
> In COLO mode, both VMs are running, and are considered in sync if the
> visible network traffic is identical. After some time, they fall out of
> sync.
>
> At this point, the two VMs have definitely diverged. Lets call the
> primary dirty bitmap set A, while the secondary dirty bitmap set B.
>
> Sets A and B are different.
>
> Under normal migration, the page data for set A will be sent from the
> primary to the secondary.
>
> However, the set difference B - A (the one in B but not in A, lets
> call this C) is out-of-date on the secondary (with respect to the
> primary) and will not be sent by the primary (to secondary), as it
> was not memory dirtied by the primary. The secondary needs C page data
> to reconstruct an exact copy of the primary at the checkpoint.
>
> The secondary cannot calculate C as it doesn't know A. Instead, the
> secondary must send B to the primary, at which point the primary
> calculates the union of A and B (lets call this D) which is all the
> pages dirtied by both the primary and the secondary, and sends all page
> data covered by D.
>
> In the general case, D is a superset of both A and B. Without the
> backchannel dirty bitmap, a COLO checkpoint can't reconstruct a valid
> copy of the primary.
>
> We transfer the dirty bitmap on libxc side, so we need to introduce back
> channel to libxc.
>
> Note: it is different from the paper. We change the original design to
> the current one, according to our following concerns:
> 1. The original design needs extra memory on Secondary host. When there's
> multiple backups on one host, the memory cost is high.
> 2. The memory cache code will be another 1k+, it will make the review
> more time consuming.
>
> Note: the back channel will be used in the patch
"will not be used" ?
I don't see any read / write to the newly introduced fd.
> libxc/restore: send dirty pfn list to primary when checkpoint under COLO
> to send dirty pfn list from secondary to primary. The patch is posted in
> another series.
>
> Signed-off-by: Yang Hongyang <hongyang.yang@easystack.cn>
> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
> CC: Ian Campbell <Ian.Campbell@citrix.com>
> CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
> CC: Wei Liu <wei.liu2@citrix.com>
> ---
[...]
>
> /*----- helper execution -----*/
> +static int dup_fd_helper(libxl__gc *gc, int fd, const char *what)
> +{
> + int dup_fd = fd;
> +
> + if (fd <= 2) {
> + dup_fd = dup(fd);
> + if (dup_fd < 0) {
> + LOGE(ERROR,"dup %s", what);
> + exit(-1);
> + }
> + }
> + libxl_fd_set_cloexec(CTX, dup_fd, 0);
> +
> + return dup_fd;
> +}
>
It would be better if introduction of this helper to be separated into a
different patch.
next prev parent reply other threads:[~2016-02-03 19:40 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-29 5:27 [PATCH v7 00/18] Prerequisite patches for COLO Wen Congyang
2016-01-29 5:27 ` [PATCH v7 01/18] libxl/remus: init checkpoint_callback in Remus setup callback Wen Congyang
2016-02-03 19:39 ` Wei Liu
2016-02-04 5:17 ` Wen Congyang
2016-01-29 5:27 ` [PATCH v7 02/18] tools/libxl: move remus code into libxl_remus.c Wen Congyang
2016-01-29 16:29 ` Konrad Rzeszutek Wilk
2016-02-03 19:39 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 03/18] tools/libxl: move save/restore code into libxl_dom_save.c Wen Congyang
2016-01-29 16:30 ` Konrad Rzeszutek Wilk
2016-02-03 19:39 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 04/18] libxl/save: Refactor libxl__domain_suspend_state Wen Congyang
2016-01-29 16:31 ` Konrad Rzeszutek Wilk
2016-02-03 19:39 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 05/18] tools/libxc: support to resume uncooperative HVM guests Wen Congyang
2016-01-29 16:30 ` Konrad Rzeszutek Wilk
2016-02-03 19:40 ` Wei Liu
2016-02-04 5:30 ` Wen Congyang
2016-01-29 5:27 ` [PATCH v7 06/18] tools/libxl: introduce enum type libxl_checkpointed_stream Wen Congyang
2016-01-29 16:34 ` Konrad Rzeszutek Wilk
2016-02-03 19:40 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 07/18] migration/save: pass checkpointed_stream from libxl to libxc Wen Congyang
2016-01-29 16:35 ` Konrad Rzeszutek Wilk
2016-02-03 19:40 ` Wei Liu
2016-02-04 5:18 ` Wen Congyang
2016-01-29 5:27 ` [PATCH v7 08/18] tools/libxl: introduce libxl__domain_restore_device_model to load qemu state Wen Congyang
2016-01-29 16:34 ` Konrad Rzeszutek Wilk
2016-02-03 19:40 ` Wei Liu
2016-02-04 5:24 ` Wen Congyang
2016-02-04 9:41 ` Wei Liu
2016-02-04 9:46 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 09/18] tools/libxl: introduce libxl__domain_common_switch_qemu_logdirty() Wen Congyang
2016-01-29 16:34 ` Konrad Rzeszutek Wilk
2016-02-03 19:40 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 10/18] tools/libxl: export logdirty_init Wen Congyang
2016-02-03 19:40 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 11/18] tools/libxl: Add back channel to allow migration target send data back Wen Congyang
2016-02-03 19:40 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 12/18] tools/libx{l, c}: add back channel to libxc Wen Congyang
2016-01-29 16:38 ` Konrad Rzeszutek Wilk
2016-02-01 5:39 ` Wen Congyang
2016-02-03 19:40 ` Wei Liu [this message]
2016-02-04 5:28 ` Wen Congyang
2016-02-04 9:25 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 13/18] tools/libxl: rename remus device to checkpoint device Wen Congyang
2016-02-03 19:40 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 14/18] tools/libxl: fix backword compatibility after the automatic renaming Wen Congyang
2016-01-29 16:32 ` Konrad Rzeszutek Wilk
2016-01-29 5:27 ` [PATCH v7 15/18] tools/libxl: adjust the indentation Wen Congyang
2016-02-03 19:40 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 16/18] tools/libxl: store remus_ops in checkpoint device state Wen Congyang
2016-02-03 19:40 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 17/18] tools/libxl: move remus state into a seperate structure Wen Congyang
2016-02-03 19:41 ` Wei Liu
2016-01-29 5:27 ` [PATCH v7 18/18] tools/libxl: seperate device init/cleanup from checkpoint device layer Wen Congyang
2016-02-03 19:41 ` Wei Liu
2016-01-29 16:43 ` [PATCH v7 00/18] Prerequisite patches for COLO Konrad Rzeszutek Wilk
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=20160203194047.GB23178@citrix.com \
--to=wei.liu2@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=eddie.dong@intel.com \
--cc=guijianfeng@cn.fujitsu.com \
--cc=hongyang.yang@easystack.cn \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=lars.kurth@citrix.com \
--cc=rshriram@cs.ubc.ca \
--cc=wency@cn.fujitsu.com \
--cc=xen-devel@lists.xen.org \
--cc=xiecl.fnst@cn.fujitsu.com \
--cc=yunhong.jiang@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 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).