All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sagi Grimberg <sagi@grimberg.me>
To: Ming Lei <ming.lei@redhat.com>, Keith Busch <kbusch@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
	linux-block@vger.kernel.org,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	"Paul E . McKenney" <paulmck@kernel.org>,
	Josh Triplett <josh@joshtriplett.org>,
	Bart Van Assche <bvanassche@acm.org>
Subject: Re: [RFC PATCH] blk-mq: implement queue quiesce via percpu_ref for BLK_MQ_F_BLOCKING
Date: Wed, 29 Jul 2020 15:42:29 -0700	[thread overview]
Message-ID: <b45fe77d-b09f-3649-8167-37ae13611093@grimberg.me> (raw)
In-Reply-To: <20200729221646.GA1706771@T590>


>>>   void blk_mq_quiesce_queue(struct request_queue *q)
>>>   {
>>> -	struct blk_mq_hw_ctx *hctx;
>>> -	unsigned int i;
>>> -	bool rcu = false;
>>> -
>>>   	blk_mq_quiesce_queue_nowait(q);
>>>   
>>> -	queue_for_each_hw_ctx(q, hctx, i) {
>>> -		if (hctx->flags & BLK_MQ_F_BLOCKING)
>>> -			synchronize_srcu(hctx->srcu);
>>> -		else
>>> -			rcu = true;
>>> -	}
>>> -	if (rcu)
>>> +	if (q->tag_set->flags & BLK_MQ_F_BLOCKING) {
>>> +		percpu_ref_kill(&q->dispatch_counter);
>>> +		wait_event(q->mq_quiesce_wq,
>>> +				percpu_ref_is_zero(&q->dispatch_counter));
>>> +	} else
>>>   		synchronize_rcu();
>>>   }
>>
>>
>>
>>> +static void hctx_lock(struct blk_mq_hw_ctx *hctx)
>>>   {
>>> -	if (!(hctx->flags & BLK_MQ_F_BLOCKING)) {
>>> -		/* shut up gcc false positive */
>>> -		*srcu_idx = 0;
>>> +	if (!(hctx->flags & BLK_MQ_F_BLOCKING))
>>>   		rcu_read_lock();
>>> -	} else
>>> -		*srcu_idx = srcu_read_lock(hctx->srcu);
>>> +	else
>>> +		percpu_ref_get(&hctx->queue->dispatch_counter);
>>>   }
>>
>> percpu_ref_get() will always succeed, even after quiesce kills it.
>> Isn't it possible that 'percpu_ref_is_zero(&q->dispatch_counter))' may
>> never reach 0? We only need to ensure that dispatchers will observe
>> blk_queue_quiesced(). That doesn't require that there are no current
>> dispatchers.
> 
> IMO it shouldn't be one issue in reality, because:
> 
> - when dispatch can't make progress, the submission side will finally
>    stop because we either run queue from submission side or request
>    completion
>   
> - submission side stops because we always have very limited requests
> 
> - completion side stops because requests queued to device is limited
> too

I don't think that any requests should pass after the kill was called,
otherwise how can we safely quiesce if requests can come in after
it?

> 
> We still can handle this case by not dispatch in case that percpu_ref_tryget()

You meant tryget_live right?

> returns false, which will change the usage into the following way:
> 
>          if (hctx_lock(hctx)) {
>          	blk_mq_sched_dispatch_requests(hctx);
>          	hctx_unlock(hctx);
> 		}
> 
> And __blk_mq_try_issue_directly() needs a bit special treatment because
> the request has to be inserted to queue after queue becomes quiesced.

Agreed.

  reply	other threads:[~2020-07-29 22:43 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28 13:49 [RFC PATCH] blk-mq: implement queue quiesce via percpu_ref for BLK_MQ_F_BLOCKING Ming Lei
2020-07-29 10:28 ` Ming Lei
2020-07-29 15:42   ` Sagi Grimberg
2020-07-29 15:49     ` Ming Lei
2020-07-29 22:37       ` Sagi Grimberg
2020-07-30 14:53         ` Ming Lei
2020-07-30 16:10           ` Sagi Grimberg
2020-07-30 18:18             ` Keith Busch
2020-07-30 18:23               ` Sagi Grimberg
2020-07-30 19:27                 ` Keith Busch
2020-07-30 19:53                   ` Jens Axboe
2020-07-30 21:03                     ` Sagi Grimberg
2020-07-31  0:33                       ` Ming Lei
2020-07-31  0:24               ` Ming Lei
2020-07-31  0:28             ` Ming Lei
2020-07-29 11:20 ` Johannes Thumshirn
2020-07-29 16:12 ` Keith Busch
2020-07-29 22:16   ` Ming Lei
2020-07-29 22:42     ` Sagi Grimberg [this message]
2020-07-30 15:05       ` Ming Lei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b45fe77d-b09f-3649-8167-37ae13611093@grimberg.me \
    --to=sagi@grimberg.me \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=hch@lst.de \
    --cc=jiangshanlai@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=kbusch@kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=ming.lei@redhat.com \
    --cc=paulmck@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.