[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
- [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver., Jitendra Kolhe, 2016/03/04
- Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver., Eric Blake, 2016/03/07
- Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver., Roman Kagan, 2016/03/10
- Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver., Jitendra Kolhe, 2016/03/11
- Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver.,
Li, Liang Z <=
- Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver., Jitendra Kolhe, 2016/03/11
- Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver., Li, Liang Z, 2016/03/11
- Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver., Jitendra Kolhe, 2016/03/11
- Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver., Jitendra Kolhe, 2016/03/15
- Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver., Roman Kagan, 2016/03/18
- Re: [Qemu-devel] [PATCH v1] migration: skip sending ram pages released by virtio-balloon driver., Jitendra Kolhe, 2016/03/22