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

[Pavel Dovgalyuk]

> From: Kevin Wolf [mailto:address@hidden
> Am 06.03.2019 um 10:37 hat Pavel Dovgalyuk geschrieben:
> > > From: Kevin Wolf [mailto:address@hidden
> > > Am 06.03.2019 um 10:18 hat Pavel Dovgalyuk geschrieben:
> > > > > 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.

Ok, I'll try it.

> 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).

Pavel Dovgalyuk