Re: [PATCH 1/2] block: generic request_queue reference counting

[Ming Lei]

On Tue, Oct 6, 2015 at 7:23 AM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
> On Sun, Oct 4, 2015 at 12:52 AM, Ming Lei <tom.leiming@xxxxxxxxx> wrote:
>> On Wed, Sep 30, 2015 at 8:41 AM, Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
>>> Allow pmem, and other synchronous/bio-based block drivers, to fallback
>>
>> Just a bit curious, why not extend it for all(both synchronous and
>> asynchrounous) bio-based drivers? As you mentioned in introductory
>> message, all bio based drivers may have this kind of problem.
>>
>> One idea I thought of is to hold the usage counter in bio life time,
>> instead of request's life time like in blk-mq.
>>
>>> on a per-cpu reference count managed by the core for tracking queue
>>> live/dead state.
>>>
>>> The existing per-cpu reference count for the blk_mq case is promoted to
>>> be used in all block i/o scenarios.  This involves initializing it by
>>> default, waiting for it to drop to zero at exit, and holding a live
>>> reference over the invocation of q->make_request_fn() in
>>
>> It isn't enough for asynchrounous bio drivers.
>
> True, but I think that support is a follow on extension of the
> mechanism.  It seems to me not as straightforward as holding a
> per-request reference or a reference over the submission path.

Given it is a general problem for all bio based drivers, it seems
better to figure out one general solution instead of the partial fix
only for synchrounous bio based drivers.

IMO, it should work by holding the usage counter in BIO's lifetime,
for example, getting it before calling q->make_request_fn(q, bio), and
putting it after bio's completion(in bio_endio()).  Even though there is
still a small window between all bio's completion and all request's
completion, and it should have been addressed easily for both
!mq_ops and mq_ops.

thanks,
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/