qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released b


From: Li, Liang Z
Subject: Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver.
Date: Fri, 11 Mar 2016 07:25:06 +0000

> On 3/10/2016 3:19 PM, Roman Kagan wrote:
> > On Fri, Mar 04, 2016 at 02:32:47PM +0530, Jitendra Kolhe wrote:
> >> Even though the pages which are returned to the host by
> >> virtio-balloon driver are zero pages, the migration algorithm will
> >> still end up scanning the entire page ram_find_and_save_block() ->
> >> ram_save_page/ ram_save_compressed_page -> save_zero_page() ->
> >> is_zero_range().  We also end-up sending some control information
> >> over network for these page during migration. This adds to total migration
> time.
> >
> > I wonder if it is the scanning for zeros or sending the whiteout which
> > affects the total migration time more.  If it is the former (as I
> > would
> > expect) then a rather local change to is_zero_range() to make use of
> > the mapping information before scanning would get you all the speedups
> > without protocol changes, interfering with postcopy etc.
> >
> > Roman.
> >
> 
> Localizing the solution to zero page scan check is a good idea. I too agree 
> that
> most of the time is send in scanning for zero page in which case we should be
> able to localize solution to is_zero_range().
> However in case of ballooned out pages (which can be seen as a subset of
> guest zero pages) we also spend a very small portion of total migration time
> in sending the control information, which can be also avoided.
>  From my tests for 16GB idle guest of which 12GB was ballooned out, the
> zero page scan time for 12GB ballooned out pages was ~1789 ms and
> save_page_header + qemu_put_byte(f, 0); for same 12GB ballooned out
> pages was ~556 ms. Total migration time was ~8000 ms

How did you do the tests? ~ 556ms seems too long for putting several bytes to 
the buffer.
It's likely the time you measured contains the portion to processes the other 
4GB guest memory pages.

Liang
 
>      if (is_zero_range(p, TARGET_PAGE_SIZE)) {
>          acct_info.dup_pages++;
>          *bytes_transferred += save_page_header(f, block,
>                                                 offset | 
> RAM_SAVE_FLAG_COMPRESS);
>          qemu_put_byte(f, 0);
>          *bytes_transferred += 1;
>          pages = 1;
>      }
> Would moving the solution to save_zero_page() be good enough?
> 
> Thanks,
> - Jitendra




reply via email to

[Prev in Thread] Current Thread [Next in Thread]