On Mar 8, 2006, at 10:35 AM, Vladislav Bolkhovitin wrote:
Bryan Henderson wrote:
Why would the queue have a greater capacity than what is needed
when you care about performance? Is there some non-performance
reason to have a giant queue?
I still think having a giant queue is not a solution to any flow
control (or, in the words of the original problem, I/O throttling)
problem. I'm even skeptical that there's any size you can make
one that would avoid queue full conditions. It would be like
avoiding difficult memory allocation algorithms by just having a
whole lot of memory.
Yes, you're correct. But can you formulate a practical common rule
working on any SCSI transport, including FC, on which a SCSI
target, which knows some limit, can tell it to an initiator, so it
will not try to queue too many commands, please? It looks like I
have no choice, except doing "giant" queue on target hoping that
initiators are smart enough to not queue so many commands that it
starts seeing timeouts.
I still don't understand why you are reluctant to return
TASK_SET_FULL or BUSY in this case; it's what the SCSI standard
supplies as the way to say "don't queue too many commands, please".
If you don't want to return TASK_SET_FULL, then yes, an effectively
unbounded command queue is your only alternative.
Regards,
-Steve
--
Steve Byan <smb@xxxxxxxxxxx>
Software Architect
Egenera, Inc.
165 Forest Street
Marlboro, MA 01752
(508) 858-3125
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
