From: Zeyu Jin <jinzeyu@huawei.com>
To: <quintela@redhat.com>, <dgilbert@redhat.com>
Cc: Ying Fang <fangying1@huawei.com>,
qemu-devel@nongnu.org, Zeyu Jin <jinzeyu@huawei.com>,
zhang.zhanghailiang@huawei.com
Subject: [RFC PATCH 6/6] doc: Update multi-thread compression doc
Date: Fri, 27 Nov 2020 15:42:42 +0800 [thread overview]
Message-ID: <20201127074242.2321-1-jinzeyu@huawei.com> (raw)
Modify the doc to fit the previous changes.
Signed-off-by: Zeyu Jin <jinzeyu@huawei.com>
Signed-off-by: Ying Fang <fangying1@huawei.com>
---
docs/multi-thread-compression.txt | 31 ++++++++++++++++++-------------
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/docs/multi-thread-compression.txt b/docs/multi-thread-compression.txt
index bb88c6bdf1..d429963cb0 100644
--- a/docs/multi-thread-compression.txt
+++ b/docs/multi-thread-compression.txt
@@ -33,14 +33,15 @@ thread compression can be used to accelerate the compression process.
The decompression speed of Zlib is at least 4 times as quick as
compression, if the source and destination CPU have equal speed,
-keeping the compression thread count 4 times the decompression
-thread count can avoid resource waste.
+and you choose Zlib as compression method, keeping the compression
+thread count 4 times the decompression thread count can avoid resource waste.
Compression level can be used to control the compression speed and the
-compression ratio. High compression ratio will take more time, level 0
-stands for no compression, level 1 stands for the best compression
-speed, and level 9 stands for the best compression ratio. Users can
-select a level number between 0 and 9.
+compression ratio. High compression ratio will take more time,
+level 1 stands for the best compression speed, and higher level means higher
+compression ration. For Zlib, users can select a level number between 0 and 9,
+where level 0 stands for no compression. For Zstd, users can select a
+level number between 1 and 22.
When to use the multiple thread compression in live migration
@@ -116,16 +117,19 @@ to support the multiple thread compression migration:
2. Activate compression on the source:
{qemu} migrate_set_capability compress on
-3. Set the compression thread count on source:
+3. Set the compression method:
+ {qemu} migrate_set_parameter compress_method zstd
+
+4. Set the compression thread count on source:
{qemu} migrate_set_parameter compress_threads 12
-4. Set the compression level on the source:
+5. Set the compression level on the source:
{qemu} migrate_set_parameter compress_level 1
-5. Set the decompression thread count on destination:
+6. Set the decompression thread count on destination:
{qemu} migrate_set_parameter decompress_threads 3
-6. Start outgoing migration:
+7. Start outgoing migration:
{qemu} migrate -d tcp:destination.host:4444
{qemu} info migrate
Capabilities: ... compress: on
@@ -136,6 +140,7 @@ The following are the default settings:
compress_threads: 8
decompress_threads: 2
compress_level: 1 (which means best speed)
+ compress_method: zlib
So, only the first two steps are required to use the multiple
thread compression in migration. You can do more if the default
@@ -143,7 +148,7 @@ settings are not appropriate.
TODO
====
-Some faster (de)compression method such as LZ4 and Quicklz can help
-to reduce the CPU consumption when doing (de)compression. If using
-these faster (de)compression method, less (de)compression threads
+Comparing to Zlib, Some faster (de)compression method such as LZ4
+and Quicklz can help to reduce the CPU consumption when doing (de)compression.
+If using these faster (de)compression method, less (de)compression threads
are needed when doing the migration.
--
2.23.0
next reply other threads:[~2020-11-27 7:50 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-27 7:42 Zeyu Jin [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-11-09 9:08 [RFC PATCH 0/6] migration: Multi-thread compression with zstd method Zeyu Jin
2020-11-09 9:08 ` [RFC PATCH 6/6] doc: Update multi-thread compression doc Zeyu Jin
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=20201127074242.2321-1-jinzeyu@huawei.com \
--to=jinzeyu@huawei.com \
--cc=dgilbert@redhat.com \
--cc=fangying1@huawei.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=zhang.zhanghailiang@huawei.com \
/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.