qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pavel Dovgalyuk
Subject: Re: [Qemu-devel] [PATCH v13 19/25] replay: add BH oneshot event for block layer
Date: Wed, 6 Mar 2019 11:33:06 +0300

> From: Kevin Wolf [mailto:address@hidden
> 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?

Pavel Dovgalyuk




reply via email to

[Prev in Thread] Current Thread [Next in Thread]