Re: [Qemu-devel] [RFC] Questions on the I/O performance of emulated host cdrom device

[Ying Fang]

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