[lkml]   [2002]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [BENCHMARK] 2.4.{18,19{-ck9},20rc1{-aa1}} with contest
    On Sun, 10 Nov 2002, Andrew Morton wrote:
    > Andrea Arcangeli wrote:
    > >
    > > > Whether the IO is synchronous or asynchronous shouldn't matter much,
    > >
    > > the fact the I/O is sync or async makes the whole difference. with sync
    > > reads the vmstat line in the read column will be always very small
    > > compared to the write column under a write flood. This can be fixed either:
    > >
    > > 1) with hacks in the elevator ala read-latency that are not generic and
    > > could decrease performance of other workloads

    It'd be nice if you specified which kind of workloads. Generic
    handwaving is easy, but if you think about this problem a bit
    more you'll see that most workloads which look like they might
    suffer at first view should be just fine in reality...

    > read-latency will only do the front-insertion if it was unable to find a
    > merge or insert on the tail-to-head search.
    > And the problem it desparately addresses is severe.

    Note that async-IO shouldn't make a big difference here, except
    maybe in synthetic benchmarks.

    This is because the stream of data in a server will be approximately
    the same regardless of whether the application is coded to use async
    IO, threads or processes and because clients still need to wait for
    the data on read while most writes are asynchronous.


    Bravely reimplemented by the knights who say "NIH".
    Current spamtrap: <a href=mailto:""></a>

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:30    [W:0.020 / U:0.792 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site