[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.020 / U:1.388 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site