Well, intentional behaviour is hardly what I would call a stall. I
thought you were implying that it would stall the queue indefinitely. I'm
fully aware that it forces the queue to wait until all outstanding
commands have completed before sending the untagged command, that's part
of the desired behaviour in that case.
> The scsi mid-layer queue push
> back system pushes all commands back to the BIO layer marked as REQ_SPECIAL
> (because the upper layer drivers generate the commands and it has no idea what
> they are supposed to be doing) if the driver cannot handle them. This means
> for those drivers (like the new adaptec) which load up the device until it
> returns a queue full (thus causing push back into the bio layer) we'd get
> stutter in the command pipeline. The cleanest solution is to allow (but not
> require) tagging of every request type.
This I'm not following. If you get a QUEUE_FULL from the adaptec driver,
then the commands you are pushing back should still be tagged and no stall
should be required beyond just waiting for any outstanding command on the
drive to complete or for a timeout to pass. It should not require any
untagged type stall where you have to drain the entire pipeline...
> I thought about doing this. The problem is that the blk layer doesn't have
> very good instrumentation for detecting the condition. The SCSI layer is the
> one that has per command timers and all the other necessaries so it can detect
> when a command should have returned and take corrective action.
I would think that, eventually, the bio layer will support I/O fencing via
tagged commands (aka, ext3 needs an I/O fence and the bio layer does as
needed to enforce that, which on scsi may mean an ordered queue tag is
generated instead of a regular tag and on IDE it may mean something else).
It will have to be able to tell that some of these conditions have been
satisfied in those cases, so I see no reason why it shouldn't be made
aware of them now. Just my $.02
-- Doug Ledford <dledford@redhat.com> 919-754-3700 x44233 Red Hat, Inc. 1801 Varsity Dr. Raleigh, NC 27606 - 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/