[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->chi
From: |
Stefan Hajnoczi |
Subject: |
Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock |
Date: |
Tue, 17 May 2022 11:59:03 +0100 |
On Wed, May 04, 2022 at 02:39:05PM +0100, Stefan Hajnoczi wrote:
> On Tue, Apr 26, 2022 at 04:51:06AM -0400, Emanuele Giuseppe Esposito wrote:
> > This is a new attempt to replace the need to take the AioContext lock to
> > protect graph modifications. In particular, we aim to remove
> > (or better, substitute) the AioContext around bdrv_replace_child_noperm,
> > since this function changes BlockDriverState's ->parents and ->children
> > lists.
> >
> > In the previous version, we decided to discard using subtree_drains to
> > protect the nodes, for different reasons: for those unfamiliar with it,
> > please see
> > https://patchew.org/QEMU/20220301142113.163174-1-eesposit@redhat.com/
>
> I reread the thread and it's unclear to me why drain is the wrong
> mechanism for protecting graph modifications. We theorized a lot but
> ultimately is this new mechanism sufficiently different from
> bdrv_drained_begin()/end() to make it worth implementing?
>
> Instead of invoking .drained_begin() callbacks to stop further I/O,
> we're now queuing coroutines (without backpressure information that
> whoever is spawning I/O needs so they can stop). The writer still waits
> for in-flight I/O to finish, including I/O not associated with the bdrv
> graph we wish to modify (because rdlock is per-AioContext and unrelated
> to a specific graph). Is this really more lightweight than drain?
>
> If I understand correctly, the original goal was to avoid the need to
> hold the AioContext lock across bdrv_replace_child_noperm(). I would
> focus on that and use drain for now.
>
> Maybe I've missed an important point about why the new mechanism is
> needed?
Ping?
Stefan
signature.asc
Description: PGP signature
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Emanuele Giuseppe Esposito, 2022/05/02
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Stefan Hajnoczi, 2022/05/04
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock,
Stefan Hajnoczi <=
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Emanuele Giuseppe Esposito, 2022/05/18
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Paolo Bonzini, 2022/05/18
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Stefan Hajnoczi, 2022/05/18
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Kevin Wolf, 2022/05/18
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Stefan Hajnoczi, 2022/05/19
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Kevin Wolf, 2022/05/19
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Stefan Hajnoczi, 2022/05/22
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Emanuele Giuseppe Esposito, 2022/05/23
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Stefan Hajnoczi, 2022/05/23
- Re: [RFC PATCH v2 0/8] Removal of AioContext lock, bs->parents and ->children: new rwlock, Emanuele Giuseppe Esposito, 2022/05/23