Giuliano Pochini wrote:
>
> > > This brings me to another point. We probably want some generic
> > > interfaces in ll_rw_blk to unplug individual queues, where you can either
> > > specify either the actual queue a kdev_t. Some of the places, (such as
> > > __wait_on_buffer()) it might make more sense to unplug just the queue
> > > related to the buffer in question rather than just unplug everything by
> > > running tq_disk. On single-disk systems there wouldn't be any appreciable
> > > difference, but if you had a lot of disks, it would probably work out to be
> > > more efficient. Something to think about....
> >
> > request_queue_t *q = blk_get_queue(dev);
> > generic_unplug_device(q);
>
> ?? I doesn't seem very different from the current (2.4t7)
>
> static void generic_unplug_device(void *data){
> request_queue_t *q = (request_queue_t *) data;
> unsigned long flags;
> spin_lock_irqsave(&io_request_lock, flags);
> __generic_unplug_device(q);
> spin_unlock_irqrestore(&io_request_lock, flags);
> }
> ...but perhaps I'm blind. Sometimes it happens after 6 hours of windows :(((
Well the stall effects the SCSI generic driver (st and
ioctls issued from the SCSI subsystem). So one problem
is the static storage class of that function (which is in
drivers/block). It is not exported either as Jens pointed
out. Also when the SCSI mid level queuing code comes
to this point, it already has io_request_lock.
Anyway one strategy for char drivers putting things on
those queues is to set q->plugged to zero and dispatch.
Actually, Jens is now proposing that the
scsi_lib::scsi_request_fn() doesn't check for "plugged"
at all. That solves my problem and saves code.
My tests show that the same "plugged" stall delays the
lilo command sometimes as well.
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
