Date: Fri, 3 Aug 2007 00:35:17 -0400 From: "Steve Schlosser" <swschlosser@gmail.com> To: aic7xxx@freebsd.org Subject: Command queuing in Rev 7.0? Message-ID: <4d362c350708022135y1f7e9abbx428ae12785cfbe45@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4d362c350708022135y1f7e9abbx428ae12785cfbe45>