qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 06/12] migration: do not detect zero page for co


From: Xiao Guangrong
Subject: Re: [Qemu-devel] [PATCH 06/12] migration: do not detect zero page for compression
Date: Fri, 29 Jun 2018 11:50:11 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0


Hi Daniel,

On 06/28/2018 05:36 PM, Daniel P. Berrangé wrote:
On Thu, Jun 28, 2018 at 05:12:39PM +0800, Xiao Guangrong wrote:


After this patch, the workload is moved to the worker thread, is it
acceptable?

It depends on your point of view. If you have spare / idle CPUs on the host,
then moving workload to a thread is ok, despite the CPU cost of compression
in that thread being much higher what what was replaced, since you won't be
taking CPU resources away from other contending workloads.

I'd venture to suggest though that we should probably *not* be optimizing for
the case of idle CPUs on the host. More realistic is to expect that the host
CPUs are near fully committed to work, and thus the (default) goal should be
to minimize CPU overhead for the host as a whole. From this POV, zero-page
detection is better than compression due to > x10 better speed.

Given the CPU overheads of compression, I think it has fairly narrow use
in migration in general when considering hosts are often highly committed
on CPU.

I understand your concern, however, it is not bad.

First, we tolerate the case that the thread runs little slowly - we do
not wait the thread becoming free, instead, we directly posted the page
out as normal (zero detecting still works for the normal page), so it
at least makes the performance not worse then the case compression is
not used.

Second we think the reasonable configuration is that the system should
have enough CPU resource to run the number of threads the user
configured. BTW, the work we will post out will make these parameters
be runtimely configurable, then a control daemon (e.g, libvirt) will
adjust them based on the current load of the system and the statistic
from QEMU. This is the topic we submitted to KVM Forum this year,
hope it can be accepted.

At last, we have a watermark to trigger live migration on a
load-balanced production, the watermark makes sure there is some free
CPU resource left for other works.

Thanks!



reply via email to

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