Re: Warning - running *really* short on DMA buffers while doingfiletransfers

Doug Ledford
2002-09-30T23:48:21Z

On Fri, Sep 27, 2002 at 03:28:47PM -0600, Justin T. Gibbs wrote:
> > 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.
>
> Did this really get fixed in 2.5? The internal queuing was completely
> broken in 2.4. Some of the known breakages were:
>
> 1) Device returns queue full with no outstanding commands from us
> (usually occurs in multi-initiator environments).

This may be fixed.

> 2) No delay after busy status so devices that will continually
> report BUSY if you hammer them with commands never come ready.

This is still broken. Plus, it has a limited number of retries before it
simply returns an I/O error, so it basically hammers the device (so it
can't get unbusy) until a set number of retries have completed then it
returns an I/O error, giving all sorts of false I/O errors on devices that
use BUSY status.

> 3) Queue is restarted as soon as any command completes even if
> you really need to throttle down the number of tags supported
> by the device.
>
> 4) No tag throttling. If tag throttling is in 2.5, does it ever
> increment the tag depth to handle devices that report temporary
> resource shortages (Atlas II and III do this all the time, other
> devices usually do this only in multi-initiator environments).

The current 2.5 mid layer is still tag stupid. It has no concept of tag
depth adjustment (although I have a patch here that implements this bit,
it really needs updating to the current kernels).

> 5) Proper transaction ordering across a queue full. The aic7xxx
> driver "requeues" all transactions that have not yet been sent
> to the device replacing the transaction that experienced the queue
> full back at the head so that ordering is maintained.
>
> No thought was put into any of these issues in 2.4, so I decided not
> to even think about trusting the mid-layer for this functionality.

No, you still can't yet, but we hope to have that fixed before the next
stable kernel series.

--
Doug Ledford <dledford@redhat.com> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606