All of lore.kernel.org
 help / color / mirror / Atom feed
From: Keith Busch <keith.busch@linux.intel.com>
To: Ming Lei <ming.lei@redhat.com>
Cc: Keith Busch <keith.busch@intel.com>, Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org,
	Bart Van Assche <bart.vanassche@wdc.com>,
	Christoph Hellwig <hch@lst.de>,
	linux-nvme@lists.infradead.org
Subject: Re: [RFC PATCH 3/3] blk-mq: Remove generation seqeunce
Date: Tue, 22 May 2018 08:20:30 -0600	[thread overview]
Message-ID: <20180522142030.GR5528@localhost.localdomain> (raw)
In-Reply-To: <20180522024910.GD20430@ming.t460p>

On Tue, May 22, 2018 at 10:49:11AM +0800, Ming Lei wrote:
> On Mon, May 21, 2018 at 05:11:31PM -0600, Keith Busch wrote:
> > -static void blk_mq_terminate_expired(struct blk_mq_hw_ctx *hctx,
> > +static void blk_mq_check_expired(struct blk_mq_hw_ctx *hctx,
> >  		struct request *rq, void *priv, bool reserved)
> >  {
> > +	unsigned long *next = priv;
> > +
> >  	/*
> > -	 * We marked @rq->aborted_gstate and waited for RCU.  If there were
> > -	 * completions that we lost to, they would have finished and
> > -	 * updated @rq->gstate by now; otherwise, the completion path is
> > -	 * now guaranteed to see @rq->aborted_gstate and yield.  If
> > -	 * @rq->aborted_gstate still matches @rq->gstate, @rq is ours.
> > +	 * Just do a quick check if it is expired before locking the request in
> > +	 * so we're not unnecessarilly synchronizing across CPUs.
> >  	 */
> > -	if (!(rq->rq_flags & RQF_MQ_TIMEOUT_EXPIRED) &&
> > -	    READ_ONCE(rq->gstate) == rq->aborted_gstate)
> > +	if (!blk_mq_req_expired(rq, next))
> > +		return;
> > +
> > +	/*
> > +	 * We have reason to believe the request may be expired. Take a
> > +	 * reference on the request to lock this request lifetime into its
> > +	 * currently allocated context to prevent it from being reallocated in
> > +	 * the event the completion by-passes this timeout handler.
> > +	 * 
> > +	 * If the reference was already released, then the driver beat the
> > +	 * timeout handler to posting a natural completion.
> > +	 */
> > +	if (!kref_get_unless_zero(&rq->ref))
> > +		return;
> 
> If this request is just completed in normal path and its state isn't
> updated yet, timeout will hold the request, and may complete this
> request again, then this req can be completed two times.

Hi Ming,

In the event the driver requests a normal completion, the timeout work
releasing the last reference doesn't do a second completion: it only
releases the request's tag back for re-allocation.

Thanks,
Keith

WARNING: multiple messages have this Message-ID (diff)
From: keith.busch@linux.intel.com (Keith Busch)
Subject: [RFC PATCH 3/3] blk-mq: Remove generation seqeunce
Date: Tue, 22 May 2018 08:20:30 -0600	[thread overview]
Message-ID: <20180522142030.GR5528@localhost.localdomain> (raw)
In-Reply-To: <20180522024910.GD20430@ming.t460p>

On Tue, May 22, 2018@10:49:11AM +0800, Ming Lei wrote:
> On Mon, May 21, 2018@05:11:31PM -0600, Keith Busch wrote:
> > -static void blk_mq_terminate_expired(struct blk_mq_hw_ctx *hctx,
> > +static void blk_mq_check_expired(struct blk_mq_hw_ctx *hctx,
> >  		struct request *rq, void *priv, bool reserved)
> >  {
> > +	unsigned long *next = priv;
> > +
> >  	/*
> > -	 * We marked @rq->aborted_gstate and waited for RCU.  If there were
> > -	 * completions that we lost to, they would have finished and
> > -	 * updated @rq->gstate by now; otherwise, the completion path is
> > -	 * now guaranteed to see @rq->aborted_gstate and yield.  If
> > -	 * @rq->aborted_gstate still matches @rq->gstate, @rq is ours.
> > +	 * Just do a quick check if it is expired before locking the request in
> > +	 * so we're not unnecessarilly synchronizing across CPUs.
> >  	 */
> > -	if (!(rq->rq_flags & RQF_MQ_TIMEOUT_EXPIRED) &&
> > -	    READ_ONCE(rq->gstate) == rq->aborted_gstate)
> > +	if (!blk_mq_req_expired(rq, next))
> > +		return;
> > +
> > +	/*
> > +	 * We have reason to believe the request may be expired. Take a
> > +	 * reference on the request to lock this request lifetime into its
> > +	 * currently allocated context to prevent it from being reallocated in
> > +	 * the event the completion by-passes this timeout handler.
> > +	 * 
> > +	 * If the reference was already released, then the driver beat the
> > +	 * timeout handler to posting a natural completion.
> > +	 */
> > +	if (!kref_get_unless_zero(&rq->ref))
> > +		return;
> 
> If this request is just completed in normal path and its state isn't
> updated yet, timeout will hold the request, and may complete this
> request again, then this req can be completed two times.

Hi Ming,

In the event the driver requests a normal completion, the timeout work
releasing the last reference doesn't do a second completion: it only
releases the request's tag back for re-allocation.

Thanks,
Keith

  parent reply	other threads:[~2018-05-22 14:20 UTC|newest]

Thread overview: 128+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-21 23:11 [RFC PATCH 0/3] blk-mq: Timeout rework Keith Busch
2018-05-21 23:11 ` Keith Busch
2018-05-21 23:11 ` [RFC PATCH 1/3] blk-mq: Reference count request usage Keith Busch
2018-05-21 23:11   ` Keith Busch
2018-05-22  2:27   ` Ming Lei
2018-05-22  2:27     ` Ming Lei
2018-05-22 15:19   ` Christoph Hellwig
2018-05-22 15:19     ` Christoph Hellwig
2018-05-21 23:11 ` [RFC PATCH 2/3] blk-mq: Fix timeout and state order Keith Busch
2018-05-21 23:11   ` Keith Busch
2018-05-22  2:28   ` Ming Lei
2018-05-22  2:28     ` Ming Lei
2018-05-22 15:24   ` Christoph Hellwig
2018-05-22 15:24     ` Christoph Hellwig
2018-05-22 16:27     ` Bart Van Assche
2018-05-22 16:27       ` Bart Van Assche
2018-05-21 23:11 ` [RFC PATCH 3/3] blk-mq: Remove generation seqeunce Keith Busch
2018-05-21 23:11   ` Keith Busch
2018-05-21 23:29   ` Bart Van Assche
2018-05-21 23:29     ` Bart Van Assche
2018-05-22 14:15     ` Keith Busch
2018-05-22 14:15       ` Keith Busch
2018-05-22 16:29       ` Bart Van Assche
2018-05-22 16:29         ` Bart Van Assche
2018-05-22 16:34         ` Keith Busch
2018-05-22 16:34           ` Keith Busch
2018-05-22 16:48           ` Bart Van Assche
2018-05-22 16:48             ` Bart Van Assche
2018-05-22  2:49   ` Ming Lei
2018-05-22  2:49     ` Ming Lei
2018-05-22  3:16     ` Jens Axboe
2018-05-22  3:16       ` Jens Axboe
2018-05-22  3:47       ` Ming Lei
2018-05-22  3:47         ` Ming Lei
2018-05-22  3:51         ` Jens Axboe
2018-05-22  3:51           ` Jens Axboe
2018-05-22  8:51           ` Ming Lei
2018-05-22  8:51             ` Ming Lei
2018-05-22 14:35             ` Jens Axboe
2018-05-22 14:35               ` Jens Axboe
2018-05-22 14:20     ` Keith Busch [this message]
2018-05-22 14:20       ` Keith Busch
2018-05-22 14:37       ` Ming Lei
2018-05-22 14:37         ` Ming Lei
2018-05-22 14:46         ` Keith Busch
2018-05-22 14:46           ` Keith Busch
2018-05-22 14:57           ` Ming Lei
2018-05-22 14:57             ` Ming Lei
2018-05-22 15:01             ` Keith Busch
2018-05-22 15:01               ` Keith Busch
2018-05-22 15:07               ` Ming Lei
2018-05-22 15:07                 ` Ming Lei
2018-05-22 15:17                 ` Keith Busch
2018-05-22 15:17                   ` Keith Busch
2018-05-22 15:23                   ` Ming Lei
2018-05-22 15:23                     ` Ming Lei
2018-05-22 16:17   ` Christoph Hellwig
2018-05-22 16:17     ` Christoph Hellwig
2018-05-23  0:34     ` Ming Lei
2018-05-23  0:34       ` Ming Lei
2018-05-23 14:35       ` Keith Busch
2018-05-23 14:35         ` Keith Busch
2018-05-24  1:52         ` Ming Lei
2018-05-24  1:52           ` Ming Lei
2018-05-23  5:48     ` Hannes Reinecke
2018-05-23  5:48       ` Hannes Reinecke
2018-07-12 18:16   ` Bart Van Assche
2018-07-12 18:16     ` Bart Van Assche
2018-07-12 19:24     ` Keith Busch
2018-07-12 19:24       ` Keith Busch
2018-07-12 22:24       ` Bart Van Assche
2018-07-12 22:24         ` Bart Van Assche
2018-07-13  1:12         ` jianchao.wang
2018-07-13  1:12           ` jianchao.wang
2018-07-13  2:40         ` jianchao.wang
2018-07-13  2:40           ` jianchao.wang
2018-07-13 15:43         ` Keith Busch
2018-07-13 15:43           ` Keith Busch
2018-07-13 15:52           ` Bart Van Assche
2018-07-13 15:52             ` Bart Van Assche
2018-07-13 18:47             ` Keith Busch
2018-07-13 18:47               ` Keith Busch
2018-07-13 23:03               ` Bart Van Assche
2018-07-13 23:03                 ` Bart Van Assche
2018-07-13 23:58                 ` Keith Busch
2018-07-13 23:58                   ` Keith Busch
2018-07-18 19:56                   ` hch
2018-07-18 19:56                     ` hch
2018-07-18 20:39                     ` hch
2018-07-18 20:39                       ` hch
2018-07-18 21:05                       ` Bart Van Assche
2018-07-18 21:05                         ` Bart Van Assche
2018-07-18 22:53                       ` Keith Busch
2018-07-18 22:53                         ` Keith Busch
2018-07-18 20:53                     ` Keith Busch
2018-07-18 20:53                       ` Keith Busch
2018-07-18 20:58                       ` Bart Van Assche
2018-07-18 20:58                         ` Bart Van Assche
2018-07-18 21:17                         ` Keith Busch
2018-07-18 21:17                           ` Keith Busch
2018-07-18 21:30                           ` Bart Van Assche
2018-07-18 21:30                             ` Bart Van Assche
2018-07-18 21:33                             ` Keith Busch
2018-07-18 21:33                               ` Keith Busch
2018-07-19 13:19                           ` hch
2018-07-19 13:19                             ` hch
2018-07-19 14:59                             ` Keith Busch
2018-07-19 14:59                               ` Keith Busch
2018-07-19 15:56                               ` Keith Busch
2018-07-19 15:56                                 ` Keith Busch
2018-07-19 16:04                                 ` Bart Van Assche
2018-07-19 16:04                                   ` Bart Van Assche
2018-07-19 16:22                                   ` Keith Busch
2018-07-19 16:22                                     ` Keith Busch
2018-07-19 16:29                                     ` hch
2018-07-19 16:29                                       ` hch
2018-07-19 20:18                                       ` Keith Busch
2018-07-19 20:18                                         ` Keith Busch
2018-07-19 13:22                       ` hch
2018-07-19 13:22                         ` hch
2018-05-21 23:29 ` [RFC PATCH 0/3] blk-mq: Timeout rework Bart Van Assche
2018-05-21 23:29   ` Bart Van Assche
2018-05-22 14:06   ` Keith Busch
2018-05-22 14:06     ` Keith Busch
2018-05-22 16:30     ` Bart Van Assche
2018-05-22 16:30       ` Bart Van Assche
2018-05-22 16:44       ` Keith Busch
2018-05-22 16:44         ` Keith Busch

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=20180522142030.GR5528@localhost.localdomain \
    --to=keith.busch@linux.intel.com \
    --cc=axboe@kernel.dk \
    --cc=bart.vanassche@wdc.com \
    --cc=hch@lst.de \
    --cc=keith.busch@intel.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-nvme@lists.infradead.org \
    --cc=ming.lei@redhat.com \
    /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.