qemu-devel
[Top][All Lists]
Advanced

[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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v3 2/2] block: disable I/O throttling on sync api
Date: Mon, 2 Apr 2012 08:31:10 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

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

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
bdrv_read()/bdrv_write().

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

Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]