On Fri, Nov 23, 2018 at 07:55:00PM +0300, Vladimir Sementsov-Ogievskiy wrote: > Hi all! > > The series brings threads to qcow2 encryption/decryption path, > like it is already done for compression. > > Based-on: Kevin's block-next branch [d3db1496c5] > > Performance gain is illustrated by the following test: > > ]# cat test.sh > #!/bin/bash > > size=1G > src=/ssd/src.raw > dst=/ssd/dst.enc.qcow2 > > echo create source for tests > ./qemu-img create -f raw "$src" $size > ./qemu-io -f raw -c "write -P 0xa 0 $size" "$src" > > for w in "" "-W"; do > echo -e "\n\nTest with additional paramter for qemu-img: '$w'\n" > > echo create target... > ./qemu-img create -f qcow2 --object secret,id=sec0,data=test -o > encrypt.format=luks,encrypt.key-secret=sec0,encrypt.iter-time=10 "$dst" $size > echo > > echo test... > time ./qemu-img convert $w -f raw --object secret,id=sec0,data=test > --target-image-opts -n "$src" > "driver=qcow2,file.filename=$dst,encrypt.key-secret=sec0" > done
Note that using iter-time=10 is removing the time penalty for opening the luks device. This is why you didn't see the significant negative performance impact of creating many QCryptoBlock instances, one for each thread. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
