lkml.org 
[lkml]   [2000]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] livelock in elevator scheduling
    Jens Axboe writes:
    > On Tue, Nov 21 2000, kumon@flab.fujitsu.co.jp wrote:
    > > I never believe it intentional. If it is true, the current kernel
    > > will be suffered from a kind of DOS attack. Yes, actually I'm a
    > > victim of it.
    >
    > The problem is caused by the too high sequence numbers in stock
    > kernel, as I said. Plus, the sequence decrementing doesn't take
    > request/buffer size into account. So the starvation _is_ limited,
    > the limit is just too high.

    Yes, current limit is 1000000 and if I/O can manage 200req/s, then it
    will expire 5000 sec after. So, I said "infinite (more than 1hour)".
    Why do you add extreme priotity to lower sector accesses, which breaks
    elevator scheduling idea?


    > If performance is down, then that problem is most likely elsewhere.
    > I/O limited benchmarking typically thrives on lots of request
    > latency -- with that comes better throughput for individual threads.

    No, the performance down caused from this point. Server benchmark has
    a standard configuration workload which consists from several kind of
    task, such as, CPU interntional, disk seq-read, seq-write, random-read,
    random-write.

    The benchmark invokes lots of processes, each corresponds to a client,
    and each accesses different portion of few large files. We have
    enough memory to hold all dirty data at onece (1GB without himem), so
    if no I/O blocking occur, all process can be run simultaneously with
    limited amount of dirty flush I/O stream.

    If some processes eagerly access relatively lower blocks, and other
    process unfortunately requests higher block read, then the process is
    blocked. Eventually this happens to large portion of processes, the
    performance goes extremely down.
    During the measurement of test10 or test11, the performance is very
    fluctuated and lots of idle time observed by vmstat. Such instability
    is not observed on test1 or test2.

    --
    Computer Systems Laboratory, Fujitsu Labs.
    kumon@flab.fujitsu.co.jp
    -
    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:47    [W:0.021 / U:1.720 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site