Re: [Qemu-devel] [PATCH v13 19/25] replay: add BH oneshot event for block layer

[Kevin Wolf <kwolf@redhat.com>]

Am 06.03.2019 um 10:37 hat Pavel Dovgalyuk geschrieben:
> > From: Kevin Wolf [mailto:kwolf@redhat.com]
> > Am 06.03.2019 um 10:18 hat Pavel Dovgalyuk geschrieben:
> > > > From: Kevin Wolf [mailto:kwolf@redhat.com]
> > > > Am 06.03.2019 um 09:33 hat Pavel Dovgalyuk geschrieben:
> > > > > > From: Kevin Wolf [mailto:kwolf@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.

So the source is going to slow down the I/O and you won't actually test
whether the possible maximum changes.

> > 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?

null-co:// doesn't access your disk at all, so if this is the only
virtual disk that has I/O, the conventional HDD doesn't hurt. But you're
right that you probably can't use your physical disk for high
performance benchmarks then.

I'm going to suggest once more to use fio for storage testing. Actually,
maybe I can find the time to do this myself on my system, too.

But anyway, I think it's good if you're at least aware that the test you
used so far was a low-performance test where any possible performance
degradations would be dwarved by both the slow physical disk and the
slow IDE interface to communicate with the guest (which also enforces to
have only one request at the same time).

Kevin