> 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? > (Testing with IDE is useless, IDE is slow, you'll never get very high > IOPS or bandwidth with it, neither before nor after your series.) SCSI or something else? Pavel Dovgalyuk
