Messages in this thread |  | | | Subject | Re: Warning - running *really* short on DMA buffers while doingfiletransfers | | Date | Fri, 27 Sep 2002 17:13:01 -0400 | | From | James Bottomley <> |
| |
> Since your drive cannot handle 253 tags, when saturated with commands, > a new command is never submitted to the drive directly. Instead the > command waits in the aic7xxx driver's queue until space is available > on the device. In FreeBSD, this never happens as tag depth is known > to, and adjusted by, the mid-layer. In Linux I must report the queue > depth without having sufficient load or history with the device to > know anything about its capabilities so I have no choice but to > throttle internally should the device support fewer tags than > initially reported to the OS. You can determine the actual device > queue depth from "cat /proc/scsi/aic7xxx/#". Run a bunch of I/O first > so that the tag depth gets locked first.
Linux is perfectly happy just to have you return 1 in queuecommand if the device won't accept the tag. The can_queue parameter represents the maximum number of outstanding commands the mid-layer will ever send. The mid-layer is happy to re-queue I/O below this limit if it cannot be accepted by the drive. In fact, that's more or less what queue plugging is about.
The only problem occurs if you return 1 from queuecommand with no other outstanding I/O for the device.
There should be no reason in 2.5 for a driver to have to implement an internal queue.
James
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |