[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 2/2] block: disable I/O throttling on sync ap
Re: [Qemu-devel] [PATCH v3 2/2] block: disable I/O throttling on sync api
Mon, 2 Apr 2012 08:31:10 +0100
On Sat, Mar 31, 2012 at 08:07:25PM +0800, Zhi Yong Wu wrote:
> On Fri, Mar 30, 2012 at 6:29 PM, Stefan Hajnoczi <address@hidden> wrote:
> > On Fri, Mar 30, 2012 at 9:50 AM, <address@hidden> wrote:
> >> + * When all sync I/O drivers are converted to async I/O, it will be
> >> restored
> >> + * to the original state.
> > The problem here is that guess_disk_lchs() uses bdrv_read(), not
> > whether device emulation uses sync or async I/O. Converting devices
> > to async I/O will not fix this.
> Yeah, but when all sync emulated devices drivers are converted to
> async mode, the code change need to be rolled back. This is what i
There are places outside device emulation that call bdrv_read(), like
guest_disk_lchs() and bdrv_commit(). We would need to convert them
before it's safe to remove the code to disable I/O throttling in
It's not okay to drop the code before all bdrv_read()/bdrv_write()
callers that are in a code path where I/O limits can be enabled have
been fixed (including guest_disk_lchs()) because a request that exceeds
I/O limits would cause QEMU to hang.
Once all devices have been converted it might be possible to temporarily
disable throttling in bdrv_read()/bdrv_write() and never disable it
permanently. This is because the bdrv_read()/bdrv_write() calls would
only come from QEMU code that is not directly driven by the guest - here
we probably don't need to apply I/O limits anyway. In other words,
devices use bdrv_aio_*() and I/O limits apply, QEMU internal code might
still use bdrv_read()/bdrv_write() and limits will not apply.
Anyway, I think it's best to drop this part of the comment because it's
more related to the disable code in bdrv_read()/bdrv_write() than to