Thanks. What about formal reviewed-by then? Pavel Dovgalyuk
Отправлено с помощью BlueMail На 14 Мар 2019 г., 17:57, в 17:57, Kevin Wolf <[email protected]> написал:п>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:[email protected]] >> > Sent: Wednesday, March 06, 2019 5:01 PM >> > To: 'Kevin Wolf' >> > Cc: 'Pavel Dovgalyuk'; [email protected]; >[email protected]; [email protected]; >> > [email protected]; [email protected]; >[email protected]; >> > [email protected]; [email protected]; [email protected]; >[email protected]; >> > [email protected]; [email protected]; >[email protected]; [email protected]; >> > [email protected]; [email protected]; >[email protected]; >> > [email protected]; [email protected] >> > Subject: RE: [PATCH v13 19/25] replay: add BH oneshot event for >block layer >> > >> > > From: Kevin Wolf [mailto:[email protected]] >> > > Am 06.03.2019 um 10:37 hat Pavel Dovgalyuk geschrieben: >> > > > > From: Kevin Wolf [mailto:[email protected]] >> > > > > 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 >> >>
