All of lore.kernel.org
 help / color / mirror / Atom feed
From: Juan Quintela <quintela@redhat.com>
To: Denis Plotnikov <dplotnikov@virtuozzo.com>
Cc: den@virtuozzo.com, qemu-devel@nongnu.org, dgilbert@redhat.com,
	armbru@redhat.com
Subject: Re: [PATCH 0/3] migration: add sztd compression
Date: Fri, 24 Jan 2020 13:43:23 +0100	[thread overview]
Message-ID: <87o8ut3tzo.fsf@secure.laptop> (raw)
In-Reply-To: <20190226131535.30361-1-dplotnikov@virtuozzo.com> (Denis Plotnikov's message of "Tue, 26 Feb 2019 16:15:32 +0300")

Denis Plotnikov <dplotnikov@virtuozzo.com> wrote:
> zstd date compression algorithm shows better performance on data compression.
> It might be useful to employ the algorithm in VM migration to reduce CPU usage.
> A user will be able to choose between those algorithms, therefor compress-type
> migration parameter is added.
>
> Here are some results of performance comparison zstd vs gzip:

Please, could you comment on the series:

[PATCH v3 00/21] Multifd Migration Compression

That series integrated zstd/zlib compression on top of multifd,
advantages over "old" compression code are:
- We don't have to copy data back and forth
- The unit of compression is 512KB instead of 4kb
- We "conserve" the compression state between packets (this is specially
  interesting for zstd, that uses dictionaries)

> host: i7-4790 8xCPU @ 3.60GHz, 16G RAM
> migration to the same host
> VM: 2xVCPU, 8G RAM total
> 5G RAM used, memory populated with postgreqsl data
> produced by pgbench performance benchmark
>
>
> Threads: 1 compress – 1 decompress
>
> zstd provides slightly less compression ratio with almost the same
> CPU usage but copes with RAM  compression roghly 2 times faster
>
> compression type              zlib       |      zstd
> ---------------------------------------------------------
> compression level          1       5     |   1       5
> compression ratio          6.92    7.05  |   6.69    6.89
> cpu idle, %                82      83    |   86      80
> time, sec                  49      71    |   26      31
> time diff to zlib, sec                      -25     -41
>
>
> Threads: 8 compress – 2 decompress
>
> zstd provides the same migration time with less cpu consumption
>
> compression type         none  |        gzip(zlib)    |          zstd
> ------------------------------------------------------------------------------
> compression level        -     |  1      5       9    |   1       5       15
> compression ratio        -     |  6.94   6.99    7.14 |   6.64    6.89    6.93
> time, sec                154   |  22     23      27   |   23      23      25
> cpu idle, %              99    |  45     30      12   |   70      52      23
> cpu idle diff to zlib          |                      |  -25%    -22%    -11%

I don't have handy results, but it looked for me like you:
- zstd has a way better latency than zlib (i.e. the packet cames sooner)
- And it compress much better

On the migration test (best possible case for a compressor, as we are
writting just one byte of each page, and we write the same value in all
pages):

- zlib: compress 512KB -> 2500 bytes
- zstd: compess 512KB -> 52 bytes (yeap, I tested several times, it
  looked too small)

See that I posted another patch to "delete" the old compression code.
Why?
- I have been unable to modify migration-test to test it and work
  reliablely (only way was to allow a really huge downtime)
- Even with slow networking (1Gigabit) I got really mixed results,
  because as it is so slow, the guest continue dirtying memory, and in
  my tests it was never a winner

Thanks, Juan.



  parent reply	other threads:[~2020-01-24 12:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-26 13:15 [Qemu-devel] [PATCH 0/3] migration: add sztd compression Denis Plotnikov
2019-02-26 13:15 ` [Qemu-devel] [PATCH 1/3] migration: rework compression code for adding more data compressors Denis Plotnikov
2019-02-26 13:15 ` [Qemu-devel] [PATCH 2/3] hmp: add compress-type parameter to migration parameters Denis Plotnikov
2019-02-26 13:15 ` [Qemu-devel] [PATCH 3/3] migration: add zstd compression Denis Plotnikov
2019-03-04 15:10 ` [Qemu-devel] [PATCH 0/3] migration: add sztd compression Denis Plotnikov
2019-03-07  8:39   ` Denis Plotnikov
2019-03-11  8:20   ` Denis Plotnikov
     [not found]     ` <5c342066-30b6-e492-e23a-cb5accbfb11a@virtuozzo.com>
     [not found]       ` <53b5c677-870e-56a0-402d-7fdc985ec3f5@virtuozzo.com>
2019-04-05 11:40         ` [Qemu-devel] [PINGl] " Denis Plotnikov
2019-04-05 11:40         ` [Qemu-devel] [PING] " Denis Plotnikov
2019-04-25 16:17           ` [Qemu-devel] [PING PING PING] " Denis Plotnikov
2019-03-06 11:32 ` [Qemu-devel] " no-reply
2020-01-24 12:43 ` Juan Quintela [this message]
2020-01-27  7:19   ` Denis Plotnikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o8ut3tzo.fsf@secure.laptop \
    --to=quintela@redhat.com \
    --cc=armbru@redhat.com \
    --cc=den@virtuozzo.com \
    --cc=dgilbert@redhat.com \
    --cc=dplotnikov@virtuozzo.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.