Re: [RFC PATCH 0/5] Removal of AioContext lock, bs->parents and ->children: proof of concept

[Stefan Hajnoczi]

On Wed, Mar 09, 2022 at 02:26:28PM +0100, Emanuele Giuseppe Esposito wrote:
> Am 02/03/2022 um 10:47 schrieb Stefan Hajnoczi:
> > On Tue, Mar 01, 2022 at 09:21:08AM -0500, Emanuele Giuseppe Esposito wrote:
> >> Possible scenarios
> >> -------------------
> >> Keeping in mind that we can only have an iothread and the main loop
> >> draining on a certain node, we could have:
> >>
> >> main loop successfully drains and then iothread tries to drain:
> >>   impossible scenario, as iothread is already stopped once main
> >>   successfully drains.
> >>
> >> iothread successfully drains and then main loop drains:
> >>   should not be a problem, as:
> >>   1) the iothread should be already "blocked" by its own drain
> > 
> > Once drained_begin() returns in the IOThread, the IOThread can do
> > anything it wants, including more submitting I/O. I don't consider that
> > "blocked", so I'm not sure what this sentence means?
> > 
> > The way the main loop thread protects itself against the IOThread is via
> > the aio "external" handler concept and block job drain callbacks, which
> > are activated by drained_begin(). They ensure that the IOThread will not
> > perform further processing that submits I/O, but the IOThread code that
> > invoked drained_begin() can still do anything it wants.
> 
> As above I think that regardless on what the iothread is doing, once the
> main loop has finished executing bdrv_drained_begin the iothread should
> not be doing anything related to the nodes that have been drained.

I agree. What I wanted to highlight is that waiting for requests to
complete is not what stops the IOThread, it's the "external" AIO handler
mechanism.

Stefan

signature.asc
Description: PGP signature