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

[Pavel Dovgalyuk]

Thanks.
What about formal reviewed-by then?

Pavel Dovgalyuk

⁣Отправлено с помощью BlueMail ​

На 14 Мар 2019 г., 17:57, в 17:57, Kevin Wolf <address@hidden> написал:п>Am 
13.03.2019 um 06:57 hat Pavel Dovgalyuk geschrieben:
>> Kevin, what about this one?
>
>I made some benchmark on my system, too, and included some cases with
>your series. I agree that there is no significant difference, so that's
>fine.
>
>Kevin
>
>> > -----Original Message-----
>> > From: Pavel Dovgalyuk [mailto:address@hidden
>> > Sent: Wednesday, March 06, 2019 5:01 PM
>> > To: 'Kevin Wolf'
>> > Cc: 'Pavel Dovgalyuk'; address@hidden;
>address@hidden; address@hidden;
>> > address@hidden; address@hidden;
>address@hidden;
>> > address@hidden; address@hidden; address@hidden;
>address@hidden;
>> > address@hidden; address@hidden;
>address@hidden; address@hidden;
>> > address@hidden; address@hidden;
>address@hidden;
>> > address@hidden; address@hidden
>> > Subject: RE: [PATCH v13 19/25] replay: add BH oneshot event for
>block layer
>> >
>> > > 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.
>> >
>> > We've made some testing with the following fio configs:
>> >
>> > [readtest]
>> > blocksize=4k
>> > filename=/dev/vda
>> > rw=randread
>> > direct=1
>> > buffered=0
>> > ioengine=libaio
>> > iodepth=32
>> >
>> > [writetest]
>> > blocksize=4k
>> > filename=/dev/vda
>> > rw=randwrite
>> > direct=1
>> > buffered=0
>> > ioengine=libaio
>> > iodepth=32
>> >
>> > One with read, one with write, and one with both.
>> >
>> > master branch:
>> > 1  read : io=1024.0MB, bw=475545KB/s, iops=118886, runt=  2205msec
>> >
>> > 2  write: io=1024.0MB, bw=445444KB/s, iops=111361, runt=  2354msec
>> >
>> > 3  read : io=1024.0MB, bw=229850KB/s, iops=57462, runt=  4562msec
>> >    write: io=1024.0MB, bw=227210KB/s, iops=56802, runt=  4615msec
>> >
>> > rr branch:
>> > 1  read : io=1024.0MB, bw=479021KB/s, iops=119755, runt=  2189msec
>> > 2  write: io=1024.0MB, bw=440763KB/s, iops=110190, runt=  2379msec
>> >
>> > 3  read : io=1024.0MB, bw=230456KB/s, iops=57614, runt=  4550msec
>> >    write: io=1024.0MB, bw=228548KB/s, iops=57136, runt=  4588msec
>> >
>> > It seems that the difference can't be measured in our environment.
>> >
>> > Pavel Dovgalyuk
>>
>>