> Optimal order is not possible unless you know the future ;-)
I appreciate that...
> The request *should* be optimally ordered within the current
> request queue state. I.e. if the queue has request for the blocks
> [4, 10000, 10005] and the 'elevator' is going 'up', you issue 4,
> then 10000. If you then get a new request for block 5, your're out
> of luck. This is the classical elevator alg. from OS course, I
> assume that's what Linux uses.
Somehow, its wasn't or isn't.
My tests we done like such:
sync();
dirty_cruft();
ioctl(fd,START_LOG,NULL);
sync();
ioctl(fd,STOP_LOG,NULL);
ioctl(fd,DUMP_LOG,&log);
where fd was the fd to a char device I used to log. ll_rw_block
requests. I would them print out the log stuff and process it with an
awk script which would show me the number of `fragments' in contain,
where a fragment was a run of increasing or decreasing values.
Looking back at stuff, for 340 outstanding requests, I might see 157
`fragments'.
Perhaps my methods were broken, but sorting stuff before a sync. did
seem to help, except I used a quick-sort at the time and used to
overflow the stack...
-cw
-
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/