All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Li Liang <liang.z.li@intel.com>, qemu-devel@nongnu.org
Cc: yang.z.zhang@intel.com, armbru@redhat.com, lcapitulino@redhat.com
Subject: Re: [Qemu-devel] [v2 1/2] docs: Add a doc about multiple compression threads
Date: Thu, 06 Nov 2014 12:25:34 +0100	[thread overview]
Message-ID: <545B5AAE.7070004@redhat.com> (raw)
In-Reply-To: <1415272128-8273-2-git-send-email-liang.z.li@intel.com>

[-- Attachment #1: Type: text/plain, Size: 6809 bytes --]

On 11/06/2014 12:08 PM, Li Liang wrote:
> Give some details about the multiple compression threads and how
> to use it in live migration.
> 
> Signed-off-by: Li Liang <liang.z.li@intel.com>
> ---
>  docs/multiple-compression-threads.txt | 128 ++++++++++++++++++++++++++++++++++
>  1 file changed, 128 insertions(+)
>  create mode 100644 docs/multiple-compression-threads.txt
> 
> diff --git a/docs/multiple-compression-threads.txt b/docs/multiple-compression-threads.txt
> new file mode 100644
> index 0000000..a5e53de
> --- /dev/null
> +++ b/docs/multiple-compression-threads.txt
> @@ -0,0 +1,128 @@
> +Use multiple (de)compression threads in live migration
> +=================================================================
> +Copyright (C) 2014 Li Liang <liang.z.li@intel.com>

Asserting copyright without also mentioning an open license is awkward
in open source (IANAL, but as I understand it, in some areas, asserting
a copyright without also granting disclaimers merely gets the default
non-open status where the file cannot be copied at all; the license is
essential to make it obvious that the copyright holder INTENDS for the
file to be copied in some circumstances).  Thus, you need to explicitly
call out GPLv2+ (even if it can be argued it is was implied by the
top-level LICENSE) or some other compatible license to be safe.

> +
> +
> +Contents:
> +=========
> +* Introduction
> +* When to use
> +* Performance
> +* Usage
> +* TODO
> +
> +Introduction
> +============
> +Instead of sending the guest memory directly, this solution will
> +compress the ram page before sending, after receiving, the data will

s/sending,/sending;/

> +be decompressed. Using compression in live migration can help
> +to reduce the data transferred about 60%, this is very useful when the
> +bandwidth is limited, and the migration time can also be reduced about
> +70% in a typical case.
> +
> +The process of compression will consume additional CPU cycles, and the
> +extra CPU cycles will increase the migration time. On the other hand,
> +the amount of data transferred will reduced, this factor can reduce
> +the migration time. If the process of the compression is quick
> +enough, then the total migration time can be reduced, and multiple
> +compression threads can be used to accelerate the compression process.
> +
> +The decompression speed of zlib is at least 4 times as quickly as

s/quickly/quick/

> +compression, if the source and destination CPU have equal speed,
> +keeping the compression thread count 4 times the decompression
> +thread count can avoid CPU 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.
> +
> +
> +When to use the multiple compression threads in live migration
> +==============================================================
> +Compression of data will consume lot of extra CPU cycles, in a system

s/lot of//
s/cycles,/cycles; so/

> +with high overhead of CPU, avoid using this feature. When the network
> +bandwidth is very limited and the CPU resource is adequate, use the

s/use the/use of/

> +multiple compression threads will be very helpful. If both the CPU and
> +the network bandwidth are adequate, use multiple compression threads

s/use/use of/

> +can still help to reduce the migration time.
> +
> +Performance
> +===========
> +Test environment:
> +
> +CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
> +Socket Count: 2
> +Ram: 128G
> +NIC: Intel I350 (10/100/1000Mbps)
> +Host OS: CentOS 7 64-bit
> +Guest OS: Ubuntu 12.10 64-bit
> +Parameter: qemu-system-x86_64 -enable-kvm -m 1024
> + /share/ia32e_ubuntu12.10.img -monitor stdio
> +
> +There is no additional application is running on the guest when doing
> +the test.
> +
> +
> +Speed limit: 32MB/s
> +---------------------------------------------------------------
> +                    | original  | compress thread: 8
> +                    |   way     | decompress thread: 2
> +                    |           | compression level: 1
> +---------------------------------------------------------------
> +total time(msec):   |  26561    |  7920
> +---------------------------------------------------------------
> +transferred ram(kB):|  877054   | 260641
> +---------------------------------------------------------------
> +throughput(mbps):   |  270.53   | 269.68
> +---------------------------------------------------------------
> +total ram(kB):      |  1057604  | 1057604
> +---------------------------------------------------------------
> +
> +
> +Speed limit: No
> +---------------------------------------------------------------
> +                    | original  | compress thread: 15
> +                    |   way     | decompress thread: 4
> +                    |           | compression level: 1
> +---------------------------------------------------------------
> +total time(msec):   |  7611     |  2888
> +---------------------------------------------------------------
> +transferred ram(kB):|  876761   | 262301
> +---------------------------------------------------------------
> +throughput(mbps):   |  943.78   | 744.27
> +---------------------------------------------------------------
> +total ram(kB):      |  1057604  | 1057604
> +---------------------------------------------------------------
> +
> +Usage
> +======
> +1. Verify the destination QEMU version is able to support the multiple
> +compression threads migration:
> +    {qemu} info_migrate_capablilites
> +    {qemu} ... compress: off ...
> +
> +2. Activate compression on the souce:
> +    {qemu} migrate_set_capability compress on
> +
> +3. Set the compression thread count on source:
> +    {qemu} migrate_set_compress_threads 10
> +
> +4. Set the compression level on the source:
> +    {qemu} migrate_set_compress_level 1
> +
> +5. Set the decompression thread count on destination:
> +    {qemu} migrate_set_decompress_threads 5
> +
> +6. Start outgoing migration:
> +    {qemu} migrate -d tcp:destination.host:4444
> +    {qemu} info migrate
> +    Capabilities: ... compress: on
> +    ...
> +
> +TODO
> +====
> +Some faster compression/decompression method such as lz4 and quicklz
> +can help to reduce the CPU consumption when doing (de)compression.
> +Less (de)compression threads are needed when doing the migration.
> 

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]

  reply	other threads:[~2014-11-06 11:25 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06 11:08 [Qemu-devel] [PATCH v2 0/2] migration: Add a new feature to do live migration Li Liang
2014-11-06 11:08 ` [Qemu-devel] [v2 1/2] docs: Add a doc about multiple compression threads Li Liang
2014-11-06 11:25   ` Eric Blake [this message]
2014-11-06 13:24   ` Dr. David Alan Gilbert
2014-11-06 13:46     ` Eric Blake
2014-11-07  2:28     ` Li, Liang Z
2014-11-06 11:08 ` [Qemu-devel] [v2 2/2] migration: Implement " Li Liang
2014-11-06 12:57   ` Eric Blake
2014-11-21  6:18     ` Zhang, Yang Z
2014-11-24  2:25     ` Li, Liang Z
2014-11-24 17:16       ` Eric Blake
2014-12-08  6:34     ` Li, Liang Z
2014-12-10  8:23       ` Li, Liang Z
2014-11-06 15:41   ` Dr. David Alan Gilbert
2014-11-21  7:01     ` Li, Liang Z
2014-11-21  7:29   ` ChenLiang
2014-11-21  7:38     ` Li, Liang Z
2014-11-21  8:17       ` ChenLiang
2014-11-21  8:35         ` Li, Liang Z
2014-11-21  8:38         ` ChenLiang
2014-11-21  8:39         ` ChenLiang

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=545B5AAE.7070004@redhat.com \
    --to=eblake@redhat.com \
    --cc=armbru@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=liang.z.li@intel.com \
    --cc=qemu-devel@nongnu.org \
    --cc=yang.z.zhang@intel.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.