From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: James Bottomley <jejb@linux.ibm.com>
Cc: John Garry <john.garry@huawei.com>,
Ming Lei <ming.lei@redhat.com>,
Bart Van Assche <bvanassche@acm.org>,
Hannes Reinecke <hare@suse.com>,
Kashyap Desai <kashyap.desai@broadcom.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>,
Christoph Hellwig <hch@lst.de>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
Sathya Prakash <sathya.prakash@broadcom.com>,
Sreekanth Reddy <sreekanth.reddy@broadcom.com>,
Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com>,
PDL-MPT-FUSIONLINUX <MPT-FusionLinux.pdl@broadcom.com>,
chenxiang <chenxiang66@hisilicon.com>
Subject: Re: About scsi device queue depth
Date: Wed, 13 Jan 2021 01:07:41 -0500 [thread overview]
Message-ID: <yq1eeip1j4u.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <d784f7ff4f61a81c4c9df96decc6b7f6d884c616.camel@linux.ibm.com> (James Bottomley's message of "Mon, 11 Jan 2021 08:40:31 -0800")
James,
> A co-operative device can help you find the optimal by returning
> QUEUE_FULL when it's fully occupied so we have a mechanism to track
> the queue full returns and change the depth interactively.
Many disk drives and SSDs only return QF/TSF when they are out of actual
command slots (so typically 255). There is often a watertight barrier
between the transport-specific command processing and the media
management code. Very sad.
So while the exponential backoff approach works great for disk arrays,
it's hit or miss with drives. And it's really hard to come up with a
good heuristic since the optimal queue depth is highly workload and
device-specific.
We had a few folks looking at managing write queue depth based on
completion latency a couple of years ago but it didn't come to fruition.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2021-01-13 6:09 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 16:21 About scsi device queue depth John Garry
2021-01-11 16:40 ` James Bottomley
2021-01-11 17:11 ` John Garry
2021-01-12 6:35 ` James Bottomley
2021-01-12 10:27 ` John Garry
2021-01-12 16:40 ` Bryan Gurney
2021-01-12 16:47 ` James Bottomley
2021-01-12 17:20 ` Bryan Gurney
2021-01-11 17:31 ` Douglas Gilbert
2021-01-13 6:07 ` Martin K. Petersen [this message]
2021-01-13 6:36 ` Damien Le Moal
2021-01-12 1:42 ` Ming Lei
2021-01-12 8:56 ` John Garry
2021-01-12 9:06 ` Ming Lei
2021-01-12 9:23 ` John Garry
2021-01-12 11:44 ` Kashyap Desai
2021-01-13 12:17 ` John Garry
2021-01-13 13:34 ` Kashyap Desai
2021-01-13 15:39 ` John Garry
2021-01-12 17:44 ` John Garry
2021-01-12 7:23 ` Hannes Reinecke
2021-01-12 9:15 ` John Garry
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=yq1eeip1j4u.fsf@ca-mkp.ca.oracle.com \
--to=martin.petersen@oracle.com \
--cc=MPT-FusionLinux.pdl@broadcom.com \
--cc=bvanassche@acm.org \
--cc=chenxiang66@hisilicon.com \
--cc=hare@suse.com \
--cc=hch@lst.de \
--cc=jejb@linux.ibm.com \
--cc=john.garry@huawei.com \
--cc=kashyap.desai@broadcom.com \
--cc=linux-scsi@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=sathya.prakash@broadcom.com \
--cc=sreekanth.reddy@broadcom.com \
--cc=suganath-prabu.subramani@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox