Chongyun,

On Mon, Mar 28, 2022 at 09:32:10AM +0800, wuc...@chinatelecom.cn wrote:
> From: Chongyun Wu <wuc...@chinatelecom.cn>
> 
> v2:
> -patch 1: remove patch_1
> 
> v1:
> -rebase to qemu/master
> 
> Overview
> ============
> This series of patches is to optimize the performance of
> online migration using dirty ring and autoconverge.
> 
> Mainly through the following aspects to do optimization:
> 1. Dynamically adjust the dirty ring collection thread to
> reduce the occurrence of ring full, thereby reducing the
> impact on customers, improving the efficiency of dirty
> page collection, and thus improving the migration efficiency.
> 
> 2. When collecting dirty pages from KVM,
> kvm_cpu_synchronize_kick_all is not called if the rate is
> limited, and it is called only once before suspending the
> virtual machine. Because kvm_cpu_synchronize_kick_all will
> become very time-consuming when the CPU is limited, and
> there will not be too many dirty pages, so it only needs
> to be called once before suspending the virtual machine to
> ensure that dirty pages will not be lost and the efficiency
> of migration is guaranteed .
> 
> 3. Based on the characteristic of collecting dirty pages
> in the dirty ring, a new dirty page rate calculation method
> is proposed to obtain a more accurate dirty page rate.
> 
> 4. Use a more accurate dirty page rate and calculate the
> matched speed limit throttle required to complete the
> migration according to the current system bandwidth and
> parameters, instead of the current time-consuming method
> of trying to get a speed limit, greatly reducing migration
> time.

Thanks for the patches.

I'm curious what's the relationship between this series and Yong's?

If talking about throttling, I do think the old auto-converge was kind of
inefficient comparing to the new per-vcpu ways of throttling at least in
either granularity or on read tolerances (e.g., dirty ring based solution
will not block vcpu readers even if the thread is heavily throttled).

We've got quite a few techniques taking care of migration convergence
issues (didn't mention postcopy yet..), and I'm wondering whether at some
point we should be more focused and make a chosen one better, rather than
building different blocks servicing the same purpose.

Thanks,

-- 
Peter Xu


Reply via email to