archive mirror
 help / color / mirror / Atom feed
From: Kashyap Desai <>
To: Jens Axboe <>,
	Bart Van Assche <>,
	linux-block <>,
	linux-scsi <>
Cc: Ming Lei <>,
	Suganath Prabu Subramani  <>,
	Sreekanth Reddy <>,
	Sathya Prakash Veerichetty <>
Subject: RE: [PATCH V2] blk-mq: Set request mapping to NULL in blk_mq_put_driver_tag
Date: Wed, 19 Dec 2018 00:34:16 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> I actually took a look at scsi_host_find_tag() - what I think needs fixing
> here is
> that it should not return a tag that isn't allocated.
> You're just looking up random stuff, that is a recipe for disaster.
> But even with that, there's no guarantee that the tag isn't going away.

Got your point. Let us fix in <mpt3sas> driver.

> The mpt3sas use case is crap. It's iterating every tag, just in case it
> needs to do
> something to it.

Many drivers in scsi layer is having similar trouble.  May be they are less
exposed. That was a main reason, I thought to provide common fix in block

> My suggestion would be to scrap that bad implementation and have
> something available for iterating busy tags instead. That'd be more
> appropriate and a lot more efficient that a random loop from 0..depth.
> If you are flushing running commands, looking up tags that aren't even
> active
> is silly and counterproductive.

We will address this issue through <mpt3sas> driver changes in two steps.
1. I can use  driver's internal memory and will not rely on request/scsi
command. Tag 0...depth loop  is not in main IO path, so what we need is
contention free access of the list. Having driver's internal memory and
array will provide that control.
2. As you suggested best way is to use busy tag iteration.  (only for blk-mq

Thanks for your feedback.


> --
> Jens Axboe

      reply	other threads:[~2018-12-18 19:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18  7:08 [PATCH V2] blk-mq: Set request mapping to NULL in blk_mq_put_driver_tag Kashyap Desai
2018-12-18  8:27 ` Hannes Reinecke
2018-12-18 16:15 ` Bart Van Assche
2018-12-18 16:18   ` Jens Axboe
2018-12-18 17:08     ` Kashyap Desai
2018-12-18 17:13       ` Jens Axboe
2018-12-18 17:48         ` Kashyap Desai
2018-12-18 17:50           ` Jens Axboe
2018-12-18 18:08             ` Kashyap Desai
2018-12-18 18:11               ` Jens Axboe
2018-12-18 18:22                 ` Kashyap Desai
2018-12-18 18:28                   ` Jens Axboe
2018-12-18 19:04                     ` Kashyap Desai [this message]

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).