All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Ming Lei <ming.lei@redhat.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-scsi@vger.kernel.org,
	"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: linux-block@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
	Sathya Prakash <sathya.prakash@broadcom.com>,
	Chaitra P B <chaitra.basappa@broadcom.com>,
	Suganath Prabu Subramani  <suganath-prabu.subramani@broadcom.com>,
	Kashyap Desai <kashyap.desai@broadcom.com>,
	Sumit Saxena <sumit.saxena@broadcom.com>,
	Shivasharan S <shivasharan.srikanteshwara@broadcom.com>,
	"Ewan D . Milne" <emilne@redhat.com>,
	Christoph Hellwig <hch@lst.de>, Hannes Reinecke <hare@suse.de>,
	Bart Van Assche <bart.vanassche@wdc.com>
Subject: Re: [PATCH 5/6] scsi: core: don't limit per-LUN queue depth for SSD when HBA needs
Date: Sun, 19 Jan 2020 12:58:24 -0800	[thread overview]
Message-ID: <5a467267-e990-45d1-4b69-18d8c0cd17b3@acm.org> (raw)
In-Reply-To: <20200119071432.18558-6-ming.lei@redhat.com>

On 2020-01-18 23:14, Ming Lei wrote:
> +static inline bool scsi_bypass_device_busy(struct scsi_device *sdev)
> +{
> +	struct Scsi_Host *shost = sdev->host;
> +
> +	if (!shost->hostt->no_device_queue_for_ssd)
> +		return false;
> +
> +	return blk_queue_nonrot(sdev->request_queue);
> +}

In other words, sdev->device_busy is maintained for all SCSI devices
except for those SSDs controlled by a SCSI LLD driver that has
no_device_queue_for_ssd set in its host template. I'd like to see
different behavior, namely that sdev->device_busy is not maintained for
any SSD except if that SSD really needs the sdev->device_busy counter.
The blacklist mechanism may be more appropriate to mark such SSDs than
the SCSI host template.

What I also noticed is that most scsi_bypass_device_busy() calls have an
exclamation mark (!) in front of these calls. I think that inverting the
return value and renaming this function into e.g.
scsi_maintain_device_busy() would result in code that is easier to read.

Thanks,

Bart.

  reply	other threads:[~2020-01-19 20:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-19  7:14 [PATCH 0/6] scsi: support bypass device busy check for some high end HBA with SSD Ming Lei
2020-01-19  7:14 ` [PATCH 1/6] scsi: mpt3sas: don't use .device_busy in device reset routine Ming Lei
2020-01-19 20:28   ` Bart Van Assche
2020-01-19  7:14 ` [PATCH 2/6] scsi: remove .for_blk_mq Ming Lei
2020-01-19 20:29   ` Bart Van Assche
2020-01-20 10:17   ` John Garry
2020-01-20 22:12   ` Elliott, Robert (Servers)
2020-01-31  6:30   ` Christoph Hellwig
2020-02-05  2:13     ` Martin K. Petersen
2020-01-19  7:14 ` [PATCH 3/6] scsi: sd: register request queue after sd_revalidate_disk is done Ming Lei
2020-01-19 20:36   ` Bart Van Assche
2020-01-19  7:14 ` [PATCH 4/6] block: freeze queue for updating QUEUE_FLAG_NONROT Ming Lei
2020-01-19 20:40   ` Bart Van Assche
2020-01-19  7:14 ` [PATCH 5/6] scsi: core: don't limit per-LUN queue depth for SSD when HBA needs Ming Lei
2020-01-19 20:58   ` Bart Van Assche [this message]
2020-01-21  4:52   ` Martin K. Petersen
2020-01-23  2:54     ` Ming Lei
2020-01-24  1:21       ` Martin K. Petersen
2020-01-24  1:59         ` Ming Lei
2020-01-24 12:43           ` Sumit Saxena
2020-01-28  4:04             ` Martin K. Petersen
2020-01-24  0:01     ` Sumanesh Samanta
2020-01-24  1:58       ` Martin K. Petersen
2020-01-24 19:41         ` Sumanesh Samanta
2020-01-28  4:22           ` Martin K. Petersen
2020-01-31 11:39             ` Ming Lei
2020-01-19  7:14 ` [PATCH 6/6] scsi: megaraid: set flag of no_device_queue_for_ssd 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=5a467267-e990-45d1-4b69-18d8c0cd17b3@acm.org \
    --to=bvanassche@acm.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=axboe@kernel.dk \
    --cc=bart.vanassche@wdc.com \
    --cc=chaitra.basappa@broadcom.com \
    --cc=emilne@redhat.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=kashyap.desai@broadcom.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ming.lei@redhat.com \
    --cc=sathya.prakash@broadcom.com \
    --cc=shivasharan.srikanteshwara@broadcom.com \
    --cc=suganath-prabu.subramani@broadcom.com \
    --cc=sumit.saxena@broadcom.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.