> I've read the patch, and it looks like it implements the sorting
> in <linux/blk.h> on a higher level (where it really should belong),
> but it still suffers from the same bug:
>
> Your algoritm, quoted from blk.h:
> /*
> * This is used in the elevator algorithm. We don't prioritise reads
> * over writes any more --- although reads are more time-critical than
> * writes, by treating them equally we increase filesystem throughput.
> * This turns out to give better overall performance. -- sct
> */
> #define IN_ORDER(s1,s2) \
> ((s1)->rq_dev < (s2)->rq_dev || (((s1)->rq_dev == (s2)->rq_dev && \
> (s1)->sector < (s2)->sector)))
>
>
> This algoritm has the distict disadvantage of flushing
> hda before hdb, and hdc (before hdd) even later.
> Much better performance can be had by having knowledge
> on the disk. Even using the partition number only
> (rq_dev &= 0x7F or rq_dev &= 0x0F) gives better results
> because then the requests to different drives will
> overlap, flushing the drives more in-parrallel.
Rik, note that IDE devices are not using a single request queue!
In general, each major has its own request queue (IDE is using
a different major for each interface). In 2.1.x, each IDE drive
has its own request queue, even if it shares an interface with
another drive.
Requests on separate IDE interfaces are generally issued in parallel
(except for special cases in which we serialize requests to work around
hardware bugs). On a single interface, the 2.1.x drive scheduling code
is available in choose_drive() in drivers/block/ide.c.
Gadi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu