Re: PATCH: scsi device queue depth adjustability patch

James Bottomley
2002-10-02T21:41:18Z

dledford@redhat.com said:
> This patch makes it possible to adjust the queue depth of a scsi
> device after it has been in use some time and you have a better idea
> of what the optimal queue depth should be. For the most part this
> should work, but my 2.5.40 test machine is blowing chunks on the
> serverworks IDE support right now so it isn't tested :-(

I note that there's a lot more than dynamic queue depth adjustment in this
patch (PPA inquiry, slave attach etc.).

How do HBA's that don't support this now work? You've taken any dependency on
scsi_host.cmd_per_lun out of the code (thus rendering it useless) so every HBA
driver now is forced to use an initial queue depth adjustment just to start
tagged command queueing. Can't we at least start with cmd_per_lun as the
default depth?

I'm not entirely happy with the idea that we control the queue depth by
adjusting the number of the device's allocated commands. I know the patch
goes to great lengths to move these kmallocs out of the critical path, but
there are certain environments (multi-initiator) where the queue depth can be
nastily and randomly variable. If the allocations were more lazy (wait a
while before freeing a struct Scsi_Cmnd to see if the queue depth goes up
again for instance) this would address some of these concerns (perhaps just
moving to a slab allocator for command blocks would do it?)

> Side note: I left the control of queue depth setting solely in the
> hands of the low level drivers since they are the *only* ones that
> can get an accurate queue depth reading at the time of any given
> QUEUE_FULL message (see what the aic7xxx_old driver has to do in the
> QUEUE_FULL handler to find out how many commands the drive has seen
> at this exact point in time vs. how many we may have queued up to the
> card, the difference in numbers can be significant). For that
> reason, the adjust_queue_depth call was made to defer the action
> until later so that it was interrupt context safe.

I appreciate that the HBA driver is the most exact counter of the queue depth,
but would it make a significant difference if the adjustments were done
globally in the mid-layer? The great advantage is that we would gain dynamic
queue depth adjustments without having to add specific code to every driver,
at the cost of not always being entirely accurate about the depth. Is there a
good argument that this really, really must be done at the LLD level given the
cost in terms of LLD modifications? You could still add hooks for those HBAs
that really want to do it themselves.

James