Re: [RFC][PATCH] scsi-misc-2.5 software enqueue when can_queue reached

[James Bottomley <James.Bottomley@steeleye.com>]

On Fri, 2003-02-28 at 20:19, Patrick Mansfield wrote:
> Hi -
> 
> Any comments or suggestions on the following patch?

Sorry for getting to this late, just returned from a nice long weekend
holiday.

> Patch is against scsi-misc-2.5.
> 
> I'm trying to break split queue_lock into a per scsi_device lock, and the
> starved code is in the way, plus it is not fair and looks like it has a
> couple of bugs. I started by trying to add a queue of request queues plus
> throttling to the current "starved" algorithm, but it was not too clean,
> so instead implemented this software enqueueing when the host can_queue
> limit is reached.

Could you elaborate on why a pending_queue (which duplicates some of the
block layer queueing functionality that we use) is a good idea.

Under the current scheme, we prep one command beyond the can_queue limit
and leave it in the block queue, so the returning commands can restart
with a fully prepped command but we still leave all the others in the
block queue for potential elevator merging. 

> This can use more resources (scsi_cmnd's) if the sum of queue_depths on a
> host is greater than can_queue, but it is fairer (when not all devices are
> hitting queue_depth limits, or if we had throttling with a throttling
> limit of 1) and simpler compared to using a queue of queues (or code
> similiar to the current starvation code).

It would certainly need some kind of throttling.  In the current code,
not taking a command off the block queue when we can't accept it gives
the elevator longer to work on merging; taking too many commands off
when we can't actually send them on might lead to the average command
size dropping.

James