Messages in this thread | | | Date | Fri, 13 Nov 1998 17:24:37 +1300 | From | Chris Wedgwood <> | Subject | Re: elevator algorithm bug in ll_rw_blk.c |
| |
On Thu, Nov 12, 1998 at 10:56:13PM -0500, Rafael Reilova wrote:
> 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/
| |