lkml.org 
[lkml]   [1998]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRE: [patch] Re: elevator algorithm bug in ll_rw_blk.c

Le 12-Nov-98 à 02:39:28, MOLNAR Ingo écrivait :
>
> On Wed, 11 Nov 1998, Philip Gladstone wrote:
>
>> Ah. All this induced me to stare at the code. It turns out that
>> there *is* a bug.
>>
>> It turns out that a new request which is added which should go
>> at the end of the current elevator pass (once we have a new
>> pass being built) currently goes to the end of the second pass.
>>
>> I.e. if you have a queue: 10 20 5 and you insert 25, then
>> you should get 10 20 25 5 and not 10 20 5 25 as currently.
>
> nicely spotted ... unless i'm missing something, this was probably one of
> the oldest Linux bugs :) the attached patch fixes it. (it's against
> 2.1.127, and it's tested with heavy IO load)

Silly question: what about _always_ inserting requests in the second pass ?

It would take some more cpu (longer request queue to scan, but the whole
request queue is not very large), the requests would be inserted farther in
the queue but less likely to be delayed by new incoming requests so I guess the
time between insertion and execution would be roughly the same, and it should
solve the starvation problem (first pass, never modified, take a finite
time to be processed, and once it's done it's the second pass that is no longer
modified, ... so if request queue contains n requests, each request is
processed after less than n steps).

Best regards,
Pierre.


-
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.030 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site