lkml.org 
[lkml]   [2000]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: (reiserfs) Re: More on 2.2.18pre2aa2

    > >It's a good way to avoid stalls, but IMHO I thing the elevator should
    >
    > Here you're talking about the latency control logic.

    Which is tightly dependent on the way we insert new rqs.

    > >not work this way. The main problem is that it doesn't minimize head
    > >movement. For example, when comes a request for a sector at the
    >
    > The algorithm that control the latency and the one that enforce the
    > ordering are two separate things.
    >
    > For example in 2.2.15 there's only the latter (2.2.15 was missing a
    > latency control mechanism).
    >
    > >beginning of the disk it goes to the beginning of the queue (it's
    > >ordered) so it will be serviced before other rqs (it picks up rqs from
    > >the head). This way the higher is the block number, more likely that
    > >rq will wait a lot.
    >
    > We're not using a SCAN ordering algorithm it's instead a CSCAN. The queue
    > can be for istance:
    >
    > 12 13 14 1 2 3
    >
    > Now insert 15 (assume 15 is the last sector of the disk):
    >
    > 12 13 14 15 1 2 3

    Rqs are added according to the IN_ORDER() condition which enforces ascending
    ordering. What does CSCAN mean ?
    ie, if the queue initially is 1 2 3 it will become 1 2 3 14.
    If it's 12 13 14 and we insert 2: 2 12 13 14.
    So your example can happen only if the list is 12 13 14 and "14" is the
    latency barrier. When we insert 15 the list becomes 12 13 14 1 2 3 15.
    Am I missing something ?

    > PS. Thanks for having read and understood the internals of the 2.4.x
    > elevator before posting your comments, it simplifies very much the
    > communication.

    I had to study it while hunting for the no-merge bug :)

    Bye.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:38    [W:0.023 / U:29.724 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site