> From: Kevin Wolf [mailto:kw...@redhat.com] > Am 06.03.2019 um 10:18 hat Pavel Dovgalyuk geschrieben: > > > From: Kevin Wolf [mailto:kw...@redhat.com] > > > Am 06.03.2019 um 09:33 hat Pavel Dovgalyuk geschrieben: > > > > > From: Kevin Wolf [mailto:kw...@redhat.com] > > > > > Am 05.03.2019 um 12:04 hat Pavel Dovgalyuk geschrieben: > > > > > > > > > > @@ -1349,8 +1351,8 @@ static BlockAIOCB > > > > > > > > > > *blk_aio_prwv(BlockBackend *blk, > int64_t > > > > > offset, > > > > > > > int > > > > > > > > > bytes, > > > > > > > > > > > > > > > > > > > > acb->has_returned = true; > > > > > > > > > > if (acb->rwco.ret != NOT_DONE) { > > > > > > > > > > - aio_bh_schedule_oneshot(blk_get_aio_context(blk), > > > > > > > > > > - blk_aio_complete_bh, acb); > > > > > > > > > > + > > > > > > > > > > replay_bh_schedule_oneshot_event(blk_get_aio_context(blk), > > > > > > > > > > + > > > > > > > > > > blk_aio_complete_bh, acb); > > > > > > > > > > } > > > > > > > > > > > > > > > > > > This, and a few other places that you convert, are in fast > > > > > > > > > paths and add > > > > > > > > > some calls that are unnecessary for non-replay cases. > > > > > > > > > > > > > > > > I don't think that this can make a noticeable slowdown, but we > > > > > > > > can run > > > > > > > > the tests if you want. > > > > > > > > We have the test suite which performs disk-intensive > > > > > > > > computation. > > > > > > > > It was created to measure the effect of running BH callbacks > > > > > > > > through > > > > > > > > the virtual timer infrastructure. > > > > > > > > > > > > > > I think this requires quite fast storage to possibly make a > > > > > > > difference. > > > > > > > > > > > > True. > > > > > > > > > > > > > Or if you don't have that, maybe a ramdisk or even a null-co:// > > > > > > > backend > > > > > > > could do the trick. Maybe null-co:// is actually the best option. > > > > > > > > > > > > We've got tests with file copying and compression on qcow2 disks. > > > > > > How the null backend can be applied there? > > > > > > > > > > With qcow2, it can't really. null-co:// would work for running > > > > > something > > > > > like fio directly against a virtual disk, without any image format > > > > > involved. Getting the image format out of the way makes things even a > > > > > little bit faster. > > > > > > > > > > Maybe we should run a micro-benchmark fio with null-co just in > > > > > addition > > > > > to your higher level tests? > > > > > > > > We run something like that: > > > > -drive file={},if=none,id=drv,snapshot -device ide-hd,drive=drv -drive > > > > file={},if=none,id=tst,snapshot -device ide-hd,drive=tst -net none > > > > -monitor stdio -- > enable- > > > kvm -m 2G > > > > > > > > I don't really get your idea. What should be added to the command line > > > > to run null-co benchmark? > > > > > > Something like: > > > > > > -drive file=null-co://,if=none,id=null -device virtio-blk,drive=null > > > > And this drive should be destination of the copy operations, right? > > I don't know your exact benchmark, but this drive should be where the > high I/O rates are, yes.
Ok. > For getting meaningful numbers, you should have I/O only on the fast > test disk (you're talking about a copy, where is source?), We used a qcow2 image as a source. > you should > use direct I/O to get the page cache of the guest out of the way, and > you should make sure that multiple requests are issued in parallel. Is this possible, if we have only conventional HDDs? Pavel Dovgalyuk
