[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] block: Factor out bdrv_run_co()
From: |
Kevin Wolf |
Subject: |
Re: [PATCH v2] block: Factor out bdrv_run_co() |
Date: |
Wed, 20 May 2020 16:49:28 +0200 |
Am 20.05.2020 um 16:05 hat Kevin Wolf geschrieben:
> Am 19.05.2020 um 19:56 hat Vladimir Sementsov-Ogievskiy geschrieben:
> > We have a few bdrv_*() functions that can either spawn a new coroutine
> > and wait for it with BDRV_POLL_WHILE() or use a fastpath if they are
> > alreeady running in a coroutine. All of them duplicate basically the
> > same code.
> >
> > Factor the common code into a new function bdrv_run_co().
> >
> > Signed-off-by: Kevin Wolf <address@hidden>
> > Signed-off-by: Vladimir Sementsov-Ogievskiy <address@hidden>
> > [Factor out bdrv_run_co_entry too]
> > ---
> >
> > Hi!
> >
> > I'm a bit lost on rebasing "block/io: safer inc/dec in_flight sections"
> > (is it needed or not?), so, I decided to send just this one patch:
> >
> > I suggest to go a bit further, and refactor that bdrv_run_co don't need
> > additional *ret argument neither NOT_DONE logic.
>
> Hm, this approach adds another indirection and bdrv_pread/pwrite still
> seems to be on some hot paths. But maybe this is just the right
> motivation to clean up qcow2 a bit and use explicit bdrv_co_*() where it
> is possible. I might take a look later.
Still not easily possible it seems. We can add a few coroutine_fn
markers here and there (and probably should do that), but the
interesting I/O is in the Qcow2Cache, which is used from basically
everywhere.
Kevin