ping
On 2018/12/29 14:33, Ying Fang wrote:
> Hi.
> Recently one of our customer complained about the I/O performance of QEMU
> emulated host cdrom device.
> I did some investigation on it and there was still some point I could not
> figure out. So I had to ask for your help.
>
> Here is the application scenario setup by our customer.
> filename.iso /dev/sr0 /dev/cdrom
> remote client --> host(cdemu) --> Linux VM
> (1)A remote client maps an iso file to x86 host machine through network using
> tcp.
> (2)The cdemu daemon then load it as a local virtual cdrom disk drive.
> (3)A VM is launched with the virtual cdrom disk drive configured.
> The VM can make use of this virtual cdrom to install an OS in the iso file.
>
> The network bandwith btw the remote client and host is 100Mbps, we test I/O
> perf using: dd if=/dev/sr0 of=/dev/null bs=32K count=100000.
> And we have
> (1) I/O perf of host side /dev/sr0 is 11MB/s;
> (2) I/O perf of /dev/cdrom inside VM is 3.8MB/s.
>
> As we can see, I/O perf of cdrom inside the VM is about 34.5% compared with
> host side.
> FlameGraph is used to find out the bottleneck of this operation and we find
> out that too much time is occupied by calling *bdrv_is_inserted*.
> Then we dig into the code and figure out that the ioctl in
> *cdrom_is_inserted* takes too much time, because it triggers
> io_schdule_timeout in kernel.
> In the code path of emulated cdrom device, each DMA I/O request consists of
> several *bdrv_is_inserted*, which degrades the I/O performance by about 31%
> in our test.
> static bool cdrom_is_inserted(BlockDriverState *bs)
> {
> BDRVRawState *s = bs->opaque;
> int ret;
>
> ret = ioctl(s->fd, CDROM_DRIVE_STATUS, CDSL_CURRENT);
> return ret == CDS_DISC_OK;
> }
> A flamegraph svg file (cdrom.svg) is attachieved in this email to show the
> code timing profile we've tested.
>
> So here is my question.
> (1) Why do we regularly check the presence of a cdrom disk drive in the code
> path? Can we do it asynchronously?
> (2) Can we drop some check point in the code path to improve the performance?
> Thanks.
>
