Command queuing in Rev 7.0?

[Steve Schlosser]

Can anyone shed some light on our command queuing problems, described
below?  I posted this a week or so ago and haven't heard anything.
Thanks!

-steve

---------- Forwarded message ----------
From: Steve Schlosser <swschlosser at gmail.com>
Date: Aug 3, 2007 12:35 AM
Subject: Command queuing in Rev 7.0?
To: aic7xxx at freebsd.org


Hello

I have been doing some experiments with command queuing, and I'm
having trouble confirming that my system is actually queuing requests
at the disk.

Here is my setup.  I have two machines, an "old" one and a "new" one,
each with an Adaptec 29160 hooked up to identical Seagate Cheetah10k7
disks.  The old system is running Debian, kernel version 2.4.27, and
dmesg reports that the aic7xxx driver Rev 6.2.36 is running.  The new
system is running Ubuntu 7.04, kernel version 2.6.20.3, and aic7xxx
Rev 7.0.

I control the queue depth by setting global_tag_depth when I load the
module.  I'm running a simple microbenchmark which issues random 4KB
reads to the disk, varying the number of concurrent requests
outstanding at the disk from 1 (no queuing) to 253 (the maximum value
allowed for global_tag_depth).  In both cases, dmesg and
/proc/scsi/aic7xxx/<n> both report the queue depth that I set when I
load the module.

On the old system, bandwidth increases as I increase queue depth,
presumably because the disk has more scheduling choices.  Bandwidth
scales from 0.7MB/s for one outstanding request to 2.0MB/s for 128
outstanding requests.

However, with the new system, I don't get the same increase in
bandwidth - it stays at 0.7MB/s regardless of the queue depth setting.
 This suggests to me that requests are not getting queued at the disk.

Any ideas why the newer driver might not be queuing requests?  Is
there another layer in the driver stack that I should be checking on?

Thanks.

-steve