All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ming Lei <tom.leiming@gmail.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Sumanesh Samanta <sumanesh.samanta@broadcom.com>,
	Linux SCSI List <linux-scsi@vger.kernel.org>,
	James Bottomley <James.Bottomley@hansenpartnership.com>,
	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>,
	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>,
	Ming Lei <ming.lei@redhat.com>,
	linux-block <linux-block@vger.kernel.org>,
	Sumit Saxena <sumit.saxena@broadcom.com>
Subject: Re: [PATCH 5/6] scsi: core: don't limit per-LUN queue depth for SSD when HBA needs
Date: Fri, 31 Jan 2020 19:39:38 +0800	[thread overview]
Message-ID: <CACVXFVMqejMZaOT0ynnMehQF4rJf32eTW2ahoYz6oE9p+GwWEg@mail.gmail.com> (raw)
In-Reply-To: <yq1blqo9plo.fsf@oracle.com>

Hi Martin,

On Tue, Jan 28, 2020 at 12:24 PM Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>
>
> Sumanesh,
>
> > Instead of relying on QUEUE_FULL and some complex heuristics of when
> > to start tracking device_busy, why can't we simply use "
> > track_queue_depth" ( along with the other flag that Ming added) to
> > decide which devices need queue depth tracking, and track device_busy
> > only for them?
>
> Because I am interested in addressing the device_busy contention problem
> for all of our non-legacy drivers. I.e. not just for controllers that
> happen to queue internally.

Can we just do it for controllers without 'track_queue_depth' and SSD now?

>
> > I am not sure how we can suddenly start tracking device_busy on the fly,
> > if we do not know how many IO are already pending for that device?
>
> We know that from the tags. It's just not hot path material.

In case of 'track_queue_depth', cost for tracking queue depth has to be paid,
which can be too big to get expected perf on high end HBA.

sbitmap might be used for this purpose, but not sure if it can scale well enough
for this purpose.


Thanks,
Ming Lei

  reply	other threads:[~2020-01-31 11:39 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
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 [this message]
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=CACVXFVMqejMZaOT0ynnMehQF4rJf32eTW2ahoYz6oE9p+GwWEg@mail.gmail.com \
    --to=tom.leiming@gmail.com \
    --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=sumanesh.samanta@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.