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