> What I tried to implement was two-way elevator seeking (SCAN). In my
> tiny benchmark that let many threads write on random files, SCAN
> showed a throughput improvement of anywhere between 0 to 20%. But I
> also noticed benefits in the original algorithm (it's fairer), so I
> don't know if my change makes sense.
the bigger problem is that dumber devices will just execute non-forwards
ordered requests. Most modern harddisks will either cache a full track, or
will reorder the request per-track anyway, but eg. a floppy disk or a
CD-ROM will execute the requests as given, and the 'downwards' queue will
perform badly. Would you mind doing the seek benchmark on your CDROM too,
just to test this theory?
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/