[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] [RFC] Questions on the I/O performance of emulated host cdr
[Qemu-devel] [RFC] Questions on the I/O performance of emulated host cdrom device
Sat, 29 Dec 2018 14:33:18 +0800
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
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
(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
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
static bool cdrom_is_inserted(BlockDriverState *bs)
BDRVRawState *s = bs->opaque;
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?