Messages in this thread |  | | From | "Eric Youngdale" <> | Subject | Re: Weirdness in block device queues. | Date | Thu, 7 Sep 2000 16:19:55 -0400 |
| |
> It is. Not unplugging the queue results in higher throughput > when running a benchmark load, but seems to really harm > system throughput (and cause stalls) in /real/ loads. > > This is most likely due to the fact that in most real life > loads we have to write data and metadata all over the place > and write clustering isn't as effective as in benchmark > loads (where we write 500MB of "data" at full speed to one > file).
Interesting.
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....
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.
-Eric
- 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/
|  |