Re: Big TCG slowdown when using zstd with aarch64

[Juan Quintela]

Thomas Huth <thuth@redhat.com> wrote:
> On 02/06/2023 11.10, Daniel P. Berrangé wrote:
> ...
>> IMHO this feels like just another example of compression being largely
>> useless. The CPU overhead of compression can't keep up with the guest
>> dirty workload, making the supposedly network bandwidth saving irrelevant.
>
> Has anybody ever shown that there is a benefit in some use cases with
> compression?

see my other reply to Daniel.

Basically now a days only migration over WAN.  Everything over a LAN or
near enough LANS, bandwidth is so cheap that it makes no sense to use
CPU to do compression.

> ... if not, we should maybe deprecate this feature and
> remove it in a couple of releases if nobody complains. That would mean
> less code to maintain, less testing effort, and likely no
> disadvantages for the users.

For multifd, I don't care, the amount of code for enabling the feature
is trivial and don't interfere with anything else:


(fix-tests-old)$ wc -l migration/multifd-z*
  326 migration/multifd-zlib.c
  317 migration/multifd-zstd.c
  643 total

And that is because we need a lot of boilerplate code to define 6
callbacks.

The compression on precopy is a complete different beast:
- It is *VERY* buggy (no races fixed there)
- It is *VERY* inneficient
  copy page to thread
  thread compress page in a different buffer
  go back to main thread
  copy page to migration stream

  And we have to reset the compression dictionaries over each page, so
  we don't get the benefits of compression.

So I can't wait the day that we can remove it.

With respect of the multifd compression, Intel AT data engine (whatever
is called this week) is able to handle the compression by itself,
i.e. without using the host CPU, so this could be a win, but I haven't
had the time to play with it.  There are patches to do this on the list,
but they are for the old compression code, not the multifd ones.  I
asked the submiter to port it to multifd, but haven't heard from him
yet.

Later, Juan.