lkml.org 
[lkml]   [1998]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2011 Jasper Spaans