From: "Darrick J. Wong" <djwong@us.ibm.com>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-scsi@vger.kernel.org, Alexis Bruemmer <alexisb@us.ibm.com>,
Mike Anderson <andmike@us.ibm.com>,
Konrad Rzeszutek <konrad@darnok.org>
Subject: [PATCH] aic94xx: Increase can_queue and cmds_per_lun
Date: Mon, 28 Aug 2006 22:23:58 -0700 [thread overview]
Message-ID: <44F3CF6E.1070000@us.ibm.com> (raw)
Hi all,
Below is a patch that sets cmd_per_lun and can_queue in the aic94xx
driver's scsi_host_template to better performing values than what's
there currently. The cmd_per_lun setting is stolen straight out of the
adp94xx source, and can_queue is derived from the max_scb value that we
calculate in asd_init_hw. To the best of my (admittedly limited)
knowledge, this method provides the correct values (can_queue = 443 in
both adp94xx and aic94xx on my 9405W) but if anybody knows better,
please enlighten me. :)
That said, the effect of leaving these values set to 1 is terrible
performance in the case of either (a) certain Maxtor SAS drives flying
solo or (b) flooding several disks with I/O simultaneously (md-raid).
There may be more scenarios where we see similar problems that I
haven't uncovered.
Just for grins, I ran bogodisk (an O_DIRECT-enabled read speed test)
against three different scenarios:
1) adp94xx 1.0.8-6, pounded into 2.6.18-rc4 [green]
2) aic94xx 1.0.2, without this patch [red]
3) aic94xx 1.0.2, with this [blue]
...with these results:
http://sweaglesw.net/~djwong/programs/bogodisk/bd_graphs/bad_sas.0.png
As you can see, the read performance is cut in half by the aic94xx
driver not getting a chance to have multiple I/Os in flight at any given
time. With the patch, the two drivers are fairly close bandwidth-wise.
Also thanks to Mike Anderson for helping me figure this out.
--D
Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
diff --git a/drivers/scsi/aic94xx/aic94xx_hwi.h b/drivers/scsi/aic94xx/aic94xx_hwi.h
index c7d5053..a2d8881 100644
--- a/drivers/scsi/aic94xx/aic94xx_hwi.h
+++ b/drivers/scsi/aic94xx/aic94xx_hwi.h
@@ -36,6 +36,9 @@
#include "aic94xx.h"
#include "aic94xx_sas.h"
+/* Leave a few empty data buffers. */
+#define ASD_FREE_SCBS 3
+
/* Define ASD_MAX_PHYS to the maximum phys ever. Currently 8. */
#define ASD_MAX_PHYS 8
#define ASD_PCBA_SN_SIZE 12
diff --git a/drivers/scsi/aic94xx/aic94xx_init.c b/drivers/scsi/aic94xx/aic94xx_init.c
index 3ec2e46..34a7b4b 100644
--- a/drivers/scsi/aic94xx/aic94xx_init.c
+++ b/drivers/scsi/aic94xx/aic94xx_init.c
@@ -71,7 +72,7 @@ static struct scsi_host_template aic94xx
.change_queue_type = sas_change_queue_type,
.bios_param = sas_bios_param,
.can_queue = 1,
- .cmd_per_lun = 1,
+ .cmd_per_lun = 2,
.this_id = -1,
.sg_tablesize = SG_ALL,
.max_sectors = SCSI_DEFAULT_MAX_SECTORS,
@@ -612,13 +616,17 @@ static int __devinit asd_pci_probe(struc
goto Err_free_cache;
asd_printk("device %s: SAS addr %llx, PCBA SN %s, %d phys, %d enabled "
- "phys, flash %s, BIOS %s%d\n",
+ "phys, flash %s, BIOS %s%d, SCBs %d\n",
pci_name(dev), SAS_ADDR(asd_ha->hw_prof.sas_addr),
asd_ha->hw_prof.pcba_sn, asd_ha->hw_prof.max_phys,
asd_ha->hw_prof.num_phys,
asd_ha->hw_prof.flash.present ? "present" : "not present",
asd_ha->hw_prof.bios.present ? "build " : "not present",
- asd_ha->hw_prof.bios.bld);
+ asd_ha->hw_prof.bios.bld,
+ asd_ha->hw_prof.max_scbs);
+
+ aic94xx_sht.can_queue = asd_ha->hw_prof.max_scbs - ASD_FREE_SCBS;
+ shost->can_queue = aic94xx_sht.can_queue;
if (use_msi)
pci_enable_msi(asd_ha->pcidev);
next reply other threads:[~2006-08-29 5:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-29 5:23 Darrick J. Wong [this message]
2006-08-30 17:19 ` [PATCH] aic94xx: Increase can_queue and cmds_per_lun James Bottomley
2006-08-30 19:03 ` Darrick J. Wong
2006-08-30 19:03 ` Darrick J. Wong
2006-08-30 19:04 ` Luben Tuikov
2006-08-30 19:25 ` James Bottomley
2006-08-31 5:29 ` Luben Tuikov
2006-08-30 20:55 ` [PATCH v3] aic94xx: Increase can_queue for better performance Darrick J. Wong
2006-08-30 21:18 ` Darrick J. Wong
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=44F3CF6E.1070000@us.ibm.com \
--to=djwong@us.ibm.com \
--cc=alexisb@us.ibm.com \
--cc=andmike@us.ibm.com \
--cc=konrad@darnok.org \
--cc=linux-kernel@vger.kernel.org \
--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