Re: location of bioq lock

The approach you suggest in the second part sounds 
interesting, except that i have no idea where i should intercept
the calls in the block layer. Any suggestion ?

Re. the first part, i don't fully follow your reasoning probably 
because i have in mind a different setting - one where the driver
has already offloaded to the scheduler (through its API) all
operations on the bioq, and where the only usage of the lock is
on an exceptional situation -- a scheduler switch -- where you
can probably tolerate some small delays.
The variant lock methods are also not much a of an issue - if a bioq uses
a supported method then it is allowed to use the pluggable
interface, otherwise it just uses whatever the default is.

	cheers
	luigi

On Tue, Jul 12, 2005 at 01:28:02PM -0600, Scott Long wrote:
...
> 
> Ah, now I understand.  The downside to exporting the lock is that
> it opens the possibility of a layer outside of the driver holding
> the lock long enough to do undesirable things like delay interrupt
> processing.  Also, allowing an outside layer to peek at the bioq
> contents breaks the assumption that most drivers have that they own
> the queue and can handle it as they see fit.  It's often times
> desirable to look at the head of the bioq but not dequeue the
> bio object until you know for sure that it'll be delivered to the
> hardware.  Also, what about in-flight bio's?  It's up to the driver
> to decide whether to complete or requeue bio's that might have been
> defered due to lack of resources or a transient errors.  How will
> the action of re-ordering the queue from an outside layer handle
> this?  And finally, if you do export a lock from the driver, you
> cannot assume that it'll be a sleep mutex.  You'll need to handle
> the possibility of a spinlock, sx lock, semaphore, etc.
> 
> An alternate approach that I would suggest is to have the disk scheduler
> freeze the block layer from delivering any new bio's while waiting for
> all of the outstanding bio's to complete, then flip the scheduler
> algorithm and allow i/o delivery to resume.  That way there is no
> need to play with driver locks, no need to rummage around in resources
> that are private to the driver, and no need to worry about in-flight
> bio's.  It also removes the need to touch every driver with an API
> change.
> 
> Scott