On Tue, Oct 15, 2002 at 02:55:46PM -0400, Jeffery, David wrote: > Dave, > > Here's a patch that should restore the queue depths to what they were before > the > queue depths change was merged in. Hopefully this well restore your lost > performance. If I don't hear or find anything bad about it, it will be > going > to Linus shortly. > > And thanks goes to Mike Anderson for his initial version. That made writing > this patch all the easier. I actually sent a patch to linus already to do this but it hasn't come through yet. However, my patch and yours differ in one key point that I don't understand. The scsi mid layer will never send you more than host->can_queue commands at one time, so why do all the scsi driver authors feel it is necessary to split their queue depth up amongst devices? Justin Gibbs is the only one that gets it right IMHO. Set the depth on each device as deep as that device can take (if that happens to be host->can_queue - 1 or such, then so be it). Then, let the mid layer and the request function worry about fairness across devices. That's its job after all. If everyone is going to moderate their queue depths like that, then we might as well yank can_queue out of the host struct entirely because *it serves no purpose*. Now, simple scsi controllers like the aic7xxx and intelligent raid controllers are two different beasts. On simple controllers, the max queue depth on a target is typically whatever that target can handle. On raid controllers, it's all up to what the firmware can handle (for all I know, the ServeRAID firmware may have one queue depth limit for total commands and a separate queue depth limit on each logical device). So, I can't say for sure what the ips driver can and can't do, but I'm relatively sure that you are artificially limiting your own performance by handling queue depths the way you are. Oh, also, host->cmd_per_lun is suppossed to be the automatic queue depth on untagged devices. 16 is typically way excessive for an untagged device (and I'm not even sure you support untagged pass-through devices on ips, and if you do I have no clue if the firmware will properly queue up untagged commands on a pass through device), so I changed that as well. So, attached are the 3 different patches I sent to linus on this driver. I would be interested to know what happens to performance on this driver if you follow my suggestion of letting the mid layer take care of watching the card's maximum queue depth and start letting the drives have queues as deep as they can handle. -- Doug Ledford 919-754-3700 x44233 Red Hat, Inc. 1801 Varsity Dr. Raleigh, NC 27606