On 17/12/2014 13:34, Paolo Bonzini wrote: > > > On 16/12/2014 21:26, Paolo Bonzini wrote: >> >>> I could reproduce this very well on a random OS image that I had around. >>> This is raw over XFS over dm-crypt, and the image is about 75% sparse >>> (8.2G used over 35G). I only get 1-2%, but still it's visible. >>> >>> However I can hardly reproduce it when using a partition directly: >>> >>> old new >>> mean 9.9565 9.9636 (+0.07%) >>> stddev 0.0405 0.0537 >>> min 9.871 9.867 >>> median 9.973 9.971 >>> max 10.01 10.053 >>> count 20 20 >>> >>> I haven't tried removing layers (e.g. fully-allocated XFS image without >>> dm-crypt). >> >> Could not reproduce it with a fully-allocated XFS image, on the contrary >> the patched QEMU is a bit faster: >> >> old new >> mean 14.83325 14.82660 >> stddev 0.016930 0.010328 >> min 14.819 14.818 >> max 14.854 14.883 >> median 14.8225 14.8255 >> count 20 20 > > Same for 50% sparse XFS image, patched QEMU a bit faster: > > old new > Mean 8.31285 8.30625 > stddev 0.03690 0.03333 > min 8.277 8.276 > max 8.378 8.382 > median 8.292 8.2905 > count 20 20
Today I cannot reproduce it even on the original testcase: old new mean 9.64175 9.60935 stddev 0.15211 0.11117 min 9.445 9.454 max 10.102 9.835 median 9.64 9.6205 count 20 20 Some notes: 1) do you have Fam's io_get_events patch? I don't, and the tests probably should be done with it. 2) "qemu-img bench" probably could also be changed to use AioContext directly instead of going through GMainLoop. That said, there is some low-hanging fruit for GMainLoop that I'll shortly send a patch for. 3) bench_cb does this: b->sector += b->bufsize; Should it shift right by >> BDRV_SECTOR_BITS? Or is it intended to do the equivalent of a random read benchmark? Paolo