lkml.org 
[lkml]   [1998]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: elevator algorithm bug in ll_rw_blk.c
Hi Peter.

>> But that's a *one-way* elevator. Ideal elevators are two-way,
>> aren't they?

> Normally you use a one-way scan. A two-way scan is unfair, it will
> service different parts of the disks diffrently. Specifically the
> edges will on average have a longer wait than the central parts.

> Imagine a request being placed just after the head passed the
> track. If it is in the central region it will at most wait for the
> head to seek 1/2+1/2=1 disk (seek to the edge and back). On the
> periphery it will have to wait at most 1+1=2.

That overlooks the fact that for a unidirectional scan, the head still
has to be scanned back across the whole width of the disk, so you're
actually saying that one is better off making all suchlike seeks taake
1+1=2 rather than letting some of them take 1/2+1/2=1 - and I have to
say that I disagree with you...

> A long seek does not take that much longer than a medium one using
> a unidirectional scan lowers the max-norm of the wait.

Nope, it RAISES it - which is also the reason why most printers have
switched over to doing bidirectional printing...

Best wishes from Riley.


-
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    [W:0.153 / U:2.768 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site