qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Migration downtime more than 5s when migrating guest wi


From: Yang Hongyang
Subject: Re: [Qemu-devel] Migration downtime more than 5s when migrating guest with massive disks
Date: Sat, 20 May 2017 08:46:08 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0


On 2017/5/20 0:46, Paolo Bonzini wrote:
> 
> 
> On 19/05/2017 14:17, Gonglei (Arei) wrote:
>>> It would.  Right now memory_region_transaction_commit() is roughly
>>> O(n^2) (n devices * n BARs), and there are n of them.
>>>
>>> Reducing memory_region_transaction_commit to O(n) would be a large
>>> change.  One idea is to share the AddressSpaceDispatch for AddressSpaces
>>> that have the same root memory region (after resolving aliases).  The
>>> starting point would be to change mem_begin/mem_commit/mem_add from a
>>> MemoryListener to an loop on the FlatView, storing the
>>> AddressSpaceDispatch in the FlatView.
>>>
>> How about do O(1) for stopping stage of live migration? 
>> Because the cpu is stopped in this phase, it wouldn't cause
>> side effects IMHO, right? 
> 
> O(1) update is probably not quite possible, but it's possible to do one
> O(n) update.  We tried doing that, but something in virtio broke.

How were you do that? did you put extra begin/commit before/after destination
guest load, so that the destination guest only do one update(of n devs) 
throughout
the whole migration?

>  I
> don't remember the details.
> 
> Paolo
> 

-- 
Thanks,
Yang




reply via email to

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