[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 0/4] Implement using Intel QAT to offload ZLIB
From: |
Peter Xu |
Subject: |
Re: [PATCH v4 0/4] Implement using Intel QAT to offload ZLIB |
Date: |
Wed, 10 Jul 2024 11:18:51 -0400 |
On Wed, Jul 10, 2024 at 01:55:23PM +0000, Liu, Yuan1 wrote:
[...]
> migrate_set_parameter max-bandwidth 1250M
> |-----------|--------|---------|----------|----------|------|------|
> |8 Channels |Total |down |throughput|pages per | send | recv |
> | |time(ms)|time(ms) |(mbps) |second | cpu %| cpu% |
> |-----------|--------|---------|----------|----------|------|------|
> |qatzip | 16630| 28| 10467| 2940235| 160| 360|
> |-----------|--------|---------|----------|----------|------|------|
> |zstd | 20165| 24| 8579| 2391465| 810| 340|
> |-----------|--------|---------|----------|----------|------|------|
> |none | 46063| 40| 10848| 330240| 45| 85|
> |-----------|--------|---------|----------|----------|------|------|
>
> QATzip's dirty page processing throughput is much higher than that no
> compression.
> In this test, the vCPUs are in idle state, so the migration can be successful
> even
> without compression.
Thanks! Maybe good material to be put into the docs/ too, if Yichen's
going to pick up your doc patch when repost.
[...]
> I don’t have much experience with postcopy, here are some of my thoughts
> 1. For write-intensive VMs, this solution can improve the migration success,
> because in a limited bandwidth network scenario, the dirty page processing
> throughput will be significantly reduced for no compression, the previous
> data includes this(pages_per_second), it means that in the no compression
> precopy, the dirty pages generated by the workload are greater than the
> migration processing, resulting in migration failure.
Yes.
>
> 2. If the VM is read-intensive or has low vCPU utilization (for example, my
> current test scenario is that the vCPUs are all idle). I think no
> compression +
> precopy + postcopy also cannot improve the migration performance, and may
> also
> cause timeout failure due to long migration time, same with no compression
> precopy.
I don't think postcopy will trigger timeout failures - postcopy should use
constant time to complete a migration, that is guest memsize / bw.
The challenge is normally on the delay of page requests higher than
precopy, but in this case it might not be a big deal. And I wonder if on
100G*2 cards it can also perform pretty well, as the delay might be minimal
even if bandwidth is throttled.
>
> 3. In my opinion, the postcopy is a good solution in this scenario(low
> network bandwidth,
> VM is not critical), because even if compression is turned on, the
> migration may still
> fail(page_per_second may still less than the new dirty pages), and it is
> hard to predict
> whether VM memory is compression-friendly.
Yes.
Thanks,
--
Peter Xu
- [PATCH v4 4/4] tests/migration: Add integration test for 'qatzip' compression method, (continued)
- [PATCH v4 4/4] tests/migration: Add integration test for 'qatzip' compression method, Yichen Wang, 2024/07/05
- [PATCH v4 1/4] meson: Introduce 'qatzip' feature to the build system, Yichen Wang, 2024/07/05
- [PATCH v4 2/4] migration: Add migration parameters for QATzip, Yichen Wang, 2024/07/05
- [PATCH v4 3/4] migration: Introduce 'qatzip' compression method, Yichen Wang, 2024/07/05
- RE: [PATCH v4 0/4] Implement using Intel QAT to offload ZLIB, Liu, Yuan1, 2024/07/09