Re: When must the io_request_lock be held?

James Bottomley
2002-08-07T23:17:09Z

andmike@us.ibm.com said:
> Maybe I am mis-reading something.

> Why would we want to go back to a model of having LL drivers
> using locks outside there domain (queue_lock). Should we not be
> moving toward having drivers use there own locks.

> I would think a future model might be to have queue_locks for
> queue operations and possible shared as a scsi device lock, a
> host_lock for host data, and LL driver locks used where the
> driver needs them.

We're not really moving back: Drivers that do their own locking today should
continue to work under the new model (it just breaks the granularity of the
io_request_lock, which was used for queueing previously). Obviously, if those
drivers move to individual queue locks instead of using the host lock for all
queues, they get greater throughput but have nastier deadlock potential.

The drivers that don't have their own locks should now rely on either the
host_lock or the queue_lock depending on what their hardware allows. The
re-entrancy of queuecommand is goverened by the programming model of the
device. For simple register and single mailbox cards, it doesn't really make
too much sense to introduce a separate card lock just so they can drop the
queue locks---It complicates the programming model and has no corresponding
performance gain.

The bottom line is that there's no reason to require all drivers to develop
their own locking scheme, but the barriers to this should be decreasing for
those drivers that can profitably do this.

James