On 11/06/2014 02:24 PM, Dr. David Alan Gilbert wrote: > * Li Liang (liang.z...@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...@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
signature.asc
Description: OpenPGP digital signature
