Messages in this thread |  | | Date | Sat, 09 Sep 2000 21:21:15 -0400 | From | Douglas Gilbert <> | Subject | Re: Weirdness in block device queues. |
| |
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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |