On Thu, Sep 07 2000, Eric Youngdale 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);
And that would be it. This is already exported and I use it in a
stand-alone module. I actually tinkered with replacing the old tq_disk
task queue with something that allows unplugging of individual queues,
exactly for wait_on_buffer/page. Didn't show much of an improvement,
but then again I didn't have so many active disk sub systems that
running tq_disk would screw the plugging of other queues. But it might
be worthwile to bring up for 2.5.
> To fix this specific problem for 2.4, the easiest and safest thing to do
> is to run tq_disk when we inject a SCSI ioctl (iff the queue is plugged).
> Right now there is no way to remove individual entries from a task queue
> without running the entire list, and calling the unplug routine while the
> thing is still in the list would *appear* to be unsafe in that if the queue
> were re-plugged the tq_disk list could be corrupted.
Right, that was the problem I faced as well. But I don't see any harm in
using generic_unplug even though the task is currently queued in tq_disk.
queue_task does not re-add a it (see include/linux/tqueue.h).
--
* Jens Axboe <[EMAIL PROTECTED]>
* SuSE Labs
-
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/
