qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Split migration bitmaps by ramblock


From: Yang Hongyang
Subject: Re: [Qemu-devel] [RFC] Split migration bitmaps by ramblock
Date: Fri, 24 Mar 2017 09:57:31 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

Hi Juan,

  First of all, I like the refactor patchset about RAMState, it makes
things clean, great!

On 2017/3/24 5:01, Juan Quintela wrote:
> Hi
> 
> This series split the migration and unsent bitmaps by ramblock.  This
> makes it easier to synchronize in small bits.  This is on top of the
> RAMState and not-hotplug series.
> 
> Why?
> 
> reason 1:
> 
> People have complained that by the time that we detect that a page is
> sent, it has already been marked dirty "again" inside kvm, so we are
> going to send it again.  On top of this patch, my idea is, for words
> of the bitmap that have any bit set, just synchonize the bitmap before
> sending the pages.  I have not looking into performance numbers yet,
> jsut asking for comments about how it is done.

Here you said 'synchonize the bitmap before sending the pages', do you
mean synchronize the bitmap from kvm? If so, I doubt the performance...
because every synchronization will require a ioctl(). If not, the
synchronization of per block is useless.

Currently, migration thread will synchronize the bitmap from kvm every
iter(migration_bitmap_sync()). The RAMBlock already has kind of per block
bitmap for this kind of sync. And the migration bitmap is used to put all
those per block bitmap together for data sending use.

> 
> reason 2:
> 
> In case where the host page is a multiple of the the TARGET_PAGE_SIZE,
> we do a lot of work when we are synchronizing the bitmaps to pass it
> to target page size.  The idea is to change the bitmaps on that
> RAMBlocks to mean host page size and not TARGET_PAGE_SIZE.
> 
> Note that there are two reason for this, ARM and PPC do things like
> guests with 4kb pages on hosts with 16/64kb hosts, and then we have
> HugePages.  Note all the workarounds that postcopy has to do because
> to work in HugePages size.
> 
> Please, comment?
> 
> Later, Juan.
> 
> Juan Quintela (1):
>   ram: Split dirty bitmap by RAMBlock
> 
>  include/exec/ram_addr.h |  13 +++-
>  migration/ram.c         | 201 
> ++++++++++++++++++------------------------------
>  2 files changed, 85 insertions(+), 129 deletions(-)
> 

-- 
Thanks,
Yang




reply via email to

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