[lkml]   [2000]   [Feb]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: elevator-starvation-4 (2.2.14 && 2.3.42)

    On Fri, 11 Feb 2000 06:10:37 -0800, Bruce Thompson
    <> said:

    > Well, yes and no. I guess my fundamental claim is that if
    > userland is able to generate requests faster than the driver can
    > fulfill them for an extended period of time then we've got a larger
    > problem than worrying about a particular request taking a long time to
    > satisfy. Indeed, I claim that as long as the driver cannot keep up
    > there will always be a pathological case where a particular request is
    > unreasonably delayed.

    > I'm not saying I have any idea what the correct solution is, but I
    > feel that tackling the request scheduling problem is less meaningful
    > if we haven't at least taken a whack at solving the request overrun
    > problem.

    But we _have_ addressed request overrun. You are confusing two related
    but quite distinct things: the flow control you refer to is simply not
    done at the request layer at all, but rather at a higher level

    First of all, user space generally does not create unbounded oustanding
    IO request. It can generate unbounded dirty data, but that's something
    different. Dirty data is cached for future writeback to disk, but that
    writeback is not under the application's control (unless the user is
    doing synchronous IO, in which case we have an obvious flow control
    mechanism through which the application's performance will be

    So, when an application is doing a lot of writing, we need to perform
    flow control to throttle the amount of dirty data allowed at once. That
    is already done, but it has nothing to do with the IO scheduling.

    Once the writeback of that dirty data commences, _then_ we need to do IO
    scheduling. In fact, Linux does this in two stages: the bdflush code
    queues IO for dirty buffers without any fancy elevator sorting at all;
    and then the IO layer services those outstanding IO requests using the
    elevator sort.


    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:56    [W:0.022 / U:68.348 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site