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


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

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...


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:45    [W:0.093 / U:0.076 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site