From: Miquel van Smoorenburg <miquels@cistron.nl>
To: James.Bottomley@SteelEye.com
Cc: linux-scsi@vger.kernel.org
Subject: make sysfs scsi queue_depth read/write [patch]
Date: Wed, 14 Jan 2004 12:41:34 +0100 [thread overview]
Message-ID: <20040114114132.GA12621@cistron.nl> (raw)
[please keep me Cc:'ed, I'm not on linux-scsi]
I have been testing with a 3ware controller over the last few weeks.
It turns out that in RAID5 mode, it performs much better if the
queue depth is limited to 64 instead of the default 254.
So I patched the 3ware driver to make this tunable through a kernel/module
command line option, documented my findings, and send all that
stuff to the (very responsive) 3ware folks who are now looking at it
to see if this fixes a problem or just the symptoms of a
bigger problem.
Then it occured to me that it would be much easier to set this
limit (which is per device, not per host anyway) though sysfs.
Since a lot of SCSI drivers have options to set the queue depth,
it probably fills a need.
Below is a patch that makes /sys/block/<dev>/device/queue_depth
a read/write variable. Minimum limit is 1, maximum limit is the
value set in host->cmd_per_lun, so it should be perfectly safe.
Since the patch is trivial and it fixes a real problem (in my case,
tuning this gains 200% performance) please consider this for
2.6.NEXT (or 2.6.mm-next).
Thanks,
Mike.
--- linux-2.6.1/drivers/scsi/scsi_sysfs.c.ORIG 2004-01-09 07:59:10.000000000 +0100
+++ linux-2.6.1/drivers/scsi/scsi_sysfs.c 2004-01-14 12:26:23.000000000 +0100
@@ -259,7 +259,6 @@
* Create the actual show/store functions and data structures.
*/
sdev_rd_attr (device_blocked, "%d\n");
-sdev_rd_attr (queue_depth, "%d\n");
sdev_rd_attr (type, "%d\n");
sdev_rd_attr (scsi_level, "%d\n");
sdev_rd_attr (vendor, "%.8s\n");
@@ -283,6 +282,22 @@
};
static DEVICE_ATTR(delete, S_IWUSR, NULL, sdev_store_delete);
+sdev_show_function(queue_depth, "%d\n")
+static ssize_t sdev_store_queue_depth(struct device *dev, const char *buf,
+ size_t count)
+{
+ int val;
+ struct scsi_device *sdev;
+ if (sscanf(buf, "%d", &val) != 1)
+ return -EINVAL;
+ sdev = to_scsi_device(dev);
+ if (!sdev || val < 1 || val > sdev->host->cmd_per_lun)
+ return -EINVAL;
+ sdev->queue_depth = val;
+ return count;
+}
+static DEVICE_ATTR(queue_depth, S_IRUGO | S_IWUSR, sdev_show_queue_depth, sdev_store_queue_depth)
+
/* Default template for device attributes. May NOT be modified */
static struct device_attribute *scsi_sysfs_sdev_attrs[] = {
&dev_attr_device_blocked,
next reply other threads:[~2004-01-14 11:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-14 11:41 Miquel van Smoorenburg [this message]
2004-01-14 11:55 ` make sysfs scsi queue_depth read/write [patch] Christoph Hellwig
2004-01-14 12:21 ` Miquel van Smoorenburg
2004-01-14 14:56 ` James Bottomley
2004-01-14 15:37 ` Miquel van Smoorenburg
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=20040114114132.GA12621@cistron.nl \
--to=miquels@cistron.nl \
--cc=James.Bottomley@SteelEye.com \
--cc=linux-scsi@vger.kernel.org \
/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