Re: [Qemu-devel] [PATCH 1/8] migration: stop compressing page in migration thread

[Xiao Guangrong]

On 03/21/2018 04:19 PM, Peter Xu wrote:
> On Fri, Mar 16, 2018 at 04:05:14PM +0800, Xiao Guangrong wrote:
> > Hi David,
> >
> > Thanks for your review.
> >
> > On 03/15/2018 06:25 PM, Dr. David Alan Gilbert wrote:
> >
> > > >    migration/ram.c | 32 ++++++++++++++++----------------
> > >
> > > Hi,
> > >     Do you have some performance numbers to show this helps?  Were those
> > > taken on a normal system or were they taken with one of the compression
> > > accelerators (which I think the compression migration was designed for)?
> >
> > Yes, i have tested it on my desktop, i7-4790 + 16G, by locally live migrate
> > the VM which has 8 vCPUs + 6G memory and the max-bandwidth is limited to 350.
> >
> > During the migration, a workload which has 8 threads repeatedly written total
> > 6G memory in the VM. Before this patchset, its bandwidth is ~25 mbps, after
> > applying, the bandwidth is ~50 mbps.
>
> Hi, Guangrong,
>
> Not really review comments, but I got some questions. :)

Your comments are always valuable to me! :)

> IIUC this patch will only change the behavior when last_sent_block
> changed.  I see that the performance is doubled after the change,
> which is really promising.  However I don't fully understand why it
> brings such a big difference considering that IMHO current code is
> sending dirty pages per-RAMBlock.  I mean, IMHO last_sent_block should
> not change frequently?  Or am I wrong?

It's depends on the configuration, each memory-region which is ram or
file backend has a RAMBlock.

Actually, more benefits comes from the fact that the performance & throughput
of the multithreads has been improved as the threads is fed by the
migration thread and the result is consumed by the migration
thread.

> Another follow-up question would be: have you measured how long time
> needed to compress a 4k page, and how many time to send it?  I think
> "sending the page" is not really meaningful considering that we just
> put a page into the buffer (which should be extremely fast since we
> don't really flush it every time), however I would be curious on how
> slow would compressing a page be.

I haven't benchmark the performance of zlib, i think it is CPU intensive
workload, particularly, there no compression-accelerator (e.g, QAT) on
our production. BTW, we were using lzo instead of zlib which worked
better for some workload.

Putting a page into buffer should depend on the network, i,e, if the
network is congested it should take long time. :)