Re: [Qemu-devel] [v2 1/2] docs: Add a doc about multiple compression threads

[Eric Blake <eblake@redhat.com>]

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

On 11/06/2014 02:24 PM, Dr. David Alan Gilbert wrote:
> * Li Liang (liang.z.li@intel.com) 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>
>> ---

>> +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.
> 
> OK, some high level questions:
>    1) How does the performance compare to running a separate compressor
> process in the stream rather than embedding it in the qemu?

Interesting question.  I wonder if libvirt should be extended to
optionally insert a compression/decompression filter in the setups it
creates.  Remember, in libvirt tunnelled mode, where libvirt is adding
TLS encryption on top of the migration data stream so that it is not
sniffable from TCP, all data is already going through the path:

source qemu -> source libvirt -> destination libvirt -> destination qemu
          Unix socket/pipe  TCP socket          Unix socket/pipe

Furthermore, libvirt is ALREADY wired up to use external compression
when doing migration to file (such as supporting multiple compression
formats for 'virsh save'), which looks like:

qemu -> compressor -> libvirt I/O helper -> file
     pipe         pipe           O_DIRECT file ops

then restoring that image with:

file -> libvirt I/O helper -> decompressor -> qemu
  O_DIRECT file ops      pipe             pipe

So adding compression in the mix seems like it would be easy for libvirt
to do:

source qemu -> compressor -> source libvirt -> destination libvirt ...
          pipe           pipe            TCP socket
   -> decompressor -> destination qemu
 pipe             pipe


Of course, with an external processor, I don't know if you can get
speedups from having multiple compression threads when all input is
coming serially from a single connection, so your approach of folding in
parallel compression threads directly into qemu may still have some
speed merits.  On the other hand, I'm not sure how your solution is
multiplexing the multiple compression threads into a single migration
stream; if you are still bottlenecked by a single migration stream, what
good do you get by adding multiple (de)compression threads, without some
way in the migration protocol to cleanly call out a fair rotation from
the independent sub-stream of each thread?

-- 
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 --]