qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 03/17] aio-wait: Increase num_waiters even in


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v2 03/17] aio-wait: Increase num_waiters even in home thread
Date: Thu, 13 Sep 2018 19:21:43 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

Am 13.09.2018 um 17:11 hat Paolo Bonzini geschrieben:
> On 13/09/2018 14:52, Kevin Wolf wrote:
> > Even if AIO_WAIT_WHILE() is called in the home context of the
> > AioContext, we still want to allow the condition to change depending on
> > other threads as long as they kick the AioWait. Specfically block jobs
> > can be running in an I/O thread and should then be able to kick a drain
> > in the main loop context.
> 
> I don't understand the scenario very well.  Why hasn't the main loop's
> drain incremented num_waiters?

We are in this path (that didn't increase num_waiters before this patch)
because drain, and therefore AIO_WAIT_WHILE(), was called from the main
thread. But draining depends on a job in a different thread, so we need
to be able to be kicked when that job finally is quiesced.

If I revert this, the test /bdrv-drain/blockjob/iothread/drain hangs.
This is a block job that works on two nodes in two different contexts.

(I think I saw this with mirror, which doesn't take additional locks
when it issues a request, so maybe there's a bit more wrong there... We
clearly need more testing with iothreads, this series probably only
scratches the surface.)

> Note I'm not against the patch---though I would hoist the
> atomic_inc/atomic_dec outside the if, since it's done in both branches.

Ok.

Kevin



reply via email to

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