From: Hongyang Yang <yanghy@cn.fujitsu.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>, xen-devel@lists.xen.org
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
wency@cn.fujitsu.com, eddie.dong@intel.com,
yunhong.jiang@intel.com, ian.jackson@eu.citrix.com,
rshriram@cs.ubc.ca
Subject: Re: [PATCH Remus v1 2/8] tools/libxc: reuse send_some_pages() in send_all_pages()
Date: Thu, 7 May 2015 21:48:58 +0800 [thread overview]
Message-ID: <554B6D4A.70702@cn.fujitsu.com> (raw)
In-Reply-To: <554B399E.2080105@citrix.com>
On 05/07/2015 06:08 PM, Andrew Cooper wrote:
> On 07/05/15 07:37, Yang Hongyang wrote:
>> introduce bitmap_set() to set the entire bitmap.
>> in send_all_pages(), set the entire bitmap and call send_some_pages().
>>
>> Signed-off-by: Yang Hongyang <yanghy@cn.fujitsu.com>
>
> Ah - I see now why you unconditionally allocated the to_send bitmap.
>
> I suppose it is probably better to have less divergence between the live
> and non-live cases, and the size of the bitmap is substantially less
> than other structures in use.
>
> In which case, can I suggest the following which partially supersedes my
> review in patch 1.
>
> * Instead of having the bitmap called "to_send", having it called
> something more appropriate like "dirty_bitmap".
> * s/send_some_pages/send_dirty_pages/ and drop the *bitmap parameter.
> ('entries' should stay as it is a useful sanity check).
>
> This way, send_all_page() logically sets all pages as dirty, then sends
> any dirty pages.
Yeah, "dirty_bitmap" sounds good, will use this name as well as change the
name send_dirty_pages.
>
> ~Andrew
>
>> ---
>> tools/libxc/xc_bitops.h | 5 +++++
>> tools/libxc/xc_sr_save.c | 41 +++++++++++------------------------------
>> 2 files changed, 16 insertions(+), 30 deletions(-)
>>
>> diff --git a/tools/libxc/xc_bitops.h b/tools/libxc/xc_bitops.h
>> index dfce3b8..cd749f4 100644
>> --- a/tools/libxc/xc_bitops.h
>> +++ b/tools/libxc/xc_bitops.h
>> @@ -26,6 +26,11 @@ static inline unsigned long *bitmap_alloc(int nr_bits)
>> return calloc(1, bitmap_size(nr_bits));
>> }
>>
>> +static inline void bitmap_set(unsigned long *addr, int nr_bits)
>> +{
>> + memset(addr, 0xff, bitmap_size(nr_bits));
>> +}
>> +
>> static inline void bitmap_clear(unsigned long *addr, int nr_bits)
>> {
>> memset(addr, 0, bitmap_size(nr_bits));
>> diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
>> index 7fed668..2993ec3 100644
>> --- a/tools/libxc/xc_sr_save.c
>> +++ b/tools/libxc/xc_sr_save.c
>> @@ -346,36 +346,6 @@ static int suspend_domain(struct xc_sr_context *ctx)
>> }
>>
>> /*
>> - * Send all pages in the guests p2m. Used as the first iteration of the live
>> - * migration loop, and for a non-live save.
>> - */
>> -static int send_all_pages(struct xc_sr_context *ctx)
>> -{
>> - xc_interface *xch = ctx->xch;
>> - xen_pfn_t p;
>> - int rc;
>> -
>> - for ( p = 0; p < ctx->save.p2m_size; ++p )
>> - {
>> - rc = add_to_batch(ctx, p);
>> - if ( rc )
>> - return rc;
>> -
>> - /* Update progress every 4MB worth of memory sent. */
>> - if ( (p & ((1U << (22 - 12)) - 1)) == 0 )
>> - xc_report_progress_step(xch, p, ctx->save.p2m_size);
>> - }
>> -
>> - rc = flush_batch(ctx);
>> - if ( rc )
>> - return rc;
>> -
>> - xc_report_progress_step(xch, ctx->save.p2m_size,
>> - ctx->save.p2m_size);
>> - return 0;
>> -}
>> -
>> -/*
>> * Send a subset of pages in the guests p2m, according to the provided bitmap.
>> * Used for each subsequent iteration of the live migration loop.
>> *
>> @@ -417,6 +387,17 @@ static int send_some_pages(struct xc_sr_context *ctx,
>> return 0;
>> }
>>
>> +/*
>> + * Send all pages in the guests p2m. Used as the first iteration of the live
>> + * migration loop, and for a non-live save.
>> + */
>> +static int send_all_pages(struct xc_sr_context *ctx)
>> +{
>> + bitmap_set(to_send, ctx->save.p2m_size);
>> +
>> + return send_some_pages(ctx, to_send, ctx->save.p2m_size);
>> +}
>> +
>> static int enable_logdirty(struct xc_sr_context *ctx)
>> {
>> xc_interface *xch = ctx->xch;
>
> .
>
--
Thanks,
Yang.
next prev parent reply other threads:[~2015-05-07 13:48 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-07 6:37 [PATCH Remus v1 0/8] Remus support for Migration-v2 Yang Hongyang
2015-05-07 6:37 ` [PATCH Remus v1 1/8] tools/libxc: adjust the memory allocation for migration Yang Hongyang
2015-05-07 9:48 ` Andrew Cooper
2015-05-07 13:42 ` Hongyang Yang
2015-05-07 13:57 ` Ian Campbell
2015-05-08 9:11 ` Hongyang Yang
2015-05-08 16:27 ` David Vrabel
2015-05-08 16:42 ` Ian Campbell
2015-05-07 14:01 ` Andrew Cooper
2015-05-07 6:37 ` [PATCH Remus v1 2/8] tools/libxc: reuse send_some_pages() in send_all_pages() Yang Hongyang
2015-05-07 10:08 ` Andrew Cooper
2015-05-07 13:48 ` Hongyang Yang [this message]
2015-05-07 6:37 ` [PATCH Remus v1 3/8] tools/libxc: introduce process_record() Yang Hongyang
2015-05-07 10:12 ` Andrew Cooper
2015-05-07 6:37 ` [PATCH Remus v1 4/8] tools/libxc: split read/handle qemu info Yang Hongyang
2015-05-07 10:48 ` Andrew Cooper
2015-05-07 13:55 ` Hongyang Yang
2015-05-07 6:37 ` [PATCH Remus v1 5/8] tools/libxc: defer the setting of HVM_PARAM_IDENT_PT Yang Hongyang
2015-05-07 10:35 ` Andrew Cooper
2015-05-07 13:59 ` Hongyang Yang
2015-05-07 15:24 ` Andrew Cooper
2015-05-08 4:49 ` Hongyang Yang
2015-05-08 8:19 ` Andrew Cooper
2015-05-07 6:37 ` [PATCH Remus v1 6/8] tools/libxc: implement Remus checkpointed save Yang Hongyang
2015-05-07 6:37 ` [PATCH Remus v1 7/8] tools/libxc: implement Remus checkpointed restore Yang Hongyang
2015-05-07 6:37 ` [PATCH Remus v1 8/8] tools/libxc: X86_PV_INFO can be sent multiple times under Remus Yang Hongyang
2015-05-07 10:58 ` Andrew Cooper
2015-05-07 14:03 ` Hongyang Yang
2015-05-07 7:04 ` [PATCH Remus v1 0/8] Remus support for Migration-v2 Hongyang Yang
2015-05-07 9:31 ` Andrew Cooper
2015-05-07 15:07 ` Hongyang Yang
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=554B6D4A.70702@cn.fujitsu.com \
--to=yanghy@cn.fujitsu.com \
--cc=andrew.cooper3@citrix.com \
--cc=eddie.dong@intel.com \
--cc=ian.campbell@citrix.com \
--cc=ian.jackson@eu.citrix.com \
--cc=rshriram@cs.ubc.ca \
--cc=wei.liu2@citrix.com \
--cc=wency@cn.fujitsu.com \
--cc=xen-devel@lists.xen.org \
--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 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.