29.04.2019 3:37, Max Reitz wrote: > On 02.04.19 17:37, Vladimir Sementsov-Ogievskiy wrote: >> v5: rebase on master, some conflicts resolved due to data-file feature >> >> 01: new patch, just move test from cover letter to a file. I really hope >> that it >> will not hang the whole series, so, if we don't want it as is or with >> really >> tiny improvements, I'd prefer to skip it and queue 02-10 first. > > Yup, noted. > >> 09: "true" parameter added to moved qcow2_pre_write_overlap_check() call due >> to >> rebase on master (both before and after patch). Seems OK, so keep >> Alberto's r-b. >> >> performance: >> >> after 01: >> # ./tests/perf/block/qcow2/convert-to-encrypted /ssd/src.raw >> /ssd/dst.enc.qcow2 >> 14.18 >> # ./tests/perf/block/qcow2/convert-to-encrypted /ssd/src.raw >> /ssd/dst.enc.qcow2 -W >> 13.77 >> >> after 10: >> # ./tests/perf/block/qcow2/convert-to-encrypted /ssd/src.raw >> /ssd/dst.enc.qcow2 >> 14.35 >> # ./tests/perf/block/qcow2/convert-to-encrypted /ssd/src.raw >> /ssd/dst.enc.qcow2 -W >> 5.62 > > Hm, I see those results as well: > > Before: > w/o -W: 7.15 > w/ -W: 6.77 > > After: > w/o -W: 7.19 > w/ -W: 3.65 > > > But with -t none, this is what I get: > > Before: > w/o -W: 15.98 > w/ -W: 10.91 > > After: > w/o -W: 19.95 > w/ -W: 11.77 > > > For good measure, on tmpfs: > > Before: > w/o -W: 6.98 > w/ -W: 6.75 > > After: > w/o -W: 7.04 > w/ -W: 3.63 > > > So it looks like the results with cache enabled are really only in the > cache. When it goes down to disk, this series seems to decrease > performance. > > To confirm whether that’s actually the case, I took another machine with > an SSD where I have more empty space and increased the size to 8 GB (not > the $size, because qemu-io doesn't like that, but well, yeah), and then > ran it again without cache: > > Before: > w/o -W: ~50 - ~60 (varies...) > w/ -W: ~50 - ~70 > > After: > w/o -W: ~60 > w/ -W: ~55 - ~85 > > > So it does seem slower, although the values vary so much that it’s > difficult to tell. > > Hmm... And on that machine, there is no difference between before and > after when using -t none. So I suppose it also depends on the device? > > > > OK, I tried using qemu-img bench. After patching it to accept --object, > these are the results I got with -t none -w on a preallocated (full) 8 > GB image: > > Before: > HDD: 17.7 s, 17.8 s, 18.0 s > SSD 1: 12.9 s, 15.8 s, 15.1 s > SSD 2: 1.8 s, 1.7 s, 1.7 s > > After: > HDD: 16.1 s, 15.8 s, 15.8 s > SSD 1: 16.3 s, 18.0 s, 17.9 s > SSD 2: 2.0 s, 1.5 s, 1.5 s > > Result #1: My SSD 1 is trash. > > Result #2: I need more requests for SSD 2 to get a useful results. > Let's try again with 2^20: > Before: 23.8, 23.5, 23.3 > After: 21.0, 20.6, 20.5 > > OK, and I can clearly see that this series increases the CPU usage > (which is good). > > > So... Hm. I suppose I conclude that this series decreases performance > on trashy SSDs? But it gets better on my HDD and on my good SSD, so... > Good thing I tested it, or something.
Interesting, thanks for testing! No idea about degradation on bad SSD.. You can try to check threads overhead by set QCOW2_MAX_THREADS to 1.. > > The only really interesting thing that came out of this is that I didn't > see an improvement with qemu-img convert (only on tmpfs), but that I do > see it with qemu-img bench. So I'm wondering why you aren't using > qemu-img bench in the test in your first patch...? > the idea was that performance tests should do one run, and there should be common script to run test several times and calculate overage. -- Best regards, Vladimir
