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?
> > Anyway, if it's not too much work for you, running some tests would be
> > good.
> >
> > > > I wonder if we could make replay optional in ./configure and then make
> > > > replay_bh_schedule_oneshot_event() a static inline function that can get
> > > > optimised away at compile time if the feature is disabled.
> > >
> > > It is coupled with icount. However, some icount calls are also lie on
> > > the fast paths and are completely useless when icount is not enabled.
> >
> > Well, the common fast path is KVM, which doesn't have icount at all, so
> > that might make it less critical. :-)
>
> I see.
>
> > I get your point, though maybe that just means that both should be
> > possible to be disabled at configure time.
>
> Right, it may be reasonable for some TCG use cases.
> This could be a separate patch set, because everything changes.
Yes, I agree.
Kevin
