[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] lock-free monitor?
From: |
Fam Zheng |
Subject: |
Re: [Qemu-devel] lock-free monitor? |
Date: |
Sun, 14 Feb 2016 14:22:10 +0800 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Tue, 02/09 13:47, Stefan Hajnoczi wrote:
> On Mon, Feb 08, 2016 at 03:17:23PM +0000, Dr. David Alan Gilbert wrote:
> > Does this make sense to everyone else, or does anyone have any better
> > suggestions?
>
> As a concrete example, any monitor command that calls bdrv_drain_all()
> can hang forever with the QEMU global mutex held if I/O requests are
> stuck (e.g. NFS mount is unreachable).
>
> bdrv_aio_cancel() can also hang but is mostly exposed to device
> emulation, not the monitor.
>
> One solution for these block layer functions is to add a timeout
> argument and let them return an error. This way the monitor and device
> emulation do not hang forever.
Yes, there are a few places in block layer invoking aio_poll() in a loop
waiting for certain events, and a disconnected network link could make QEMU
hang. In these cases a timeout is a huge improvement. Maybe we can mark the
BDS as "hanging" (-EIO is returned for all further requests) and let
bdrv_drain_all() return.
>
> The benefit of the timeout is that both monitor and device emulation
> hangs are tackled. It also doesn't require monitor changes.
>
> I'm not sure who chooses the timeout value and which value makes sense
> (policy vs mechanism separation)...
Default to 30 seconds like Linux, and make it tunable through command line
options as well as QMP?
Fam