lkml.org 
[lkml]   [1998]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: elevator algorithm bug in ll_rw_blk.c
    From
    Date
    "Stephen C. Tweedie" <sct@redhat.com> writes:
    >
    > The way it actually works, sequential writes tend to be kept in
    > sequential order in the buffer cache lists, so the typical cases work
    > pretty well. All the benchmarks show that sequential filesystem writes
    > work very well.
    >

    Unfortunately, there's a case where it frequently works very very
    badly; That's when you have a LOT of disk cache (150 - 200meg) and a
    fast writer producing a lot of data).

    In this case, the write performance frequently goes abysmal, even tho
    it's sequential writing. 'Abysmal' to the tune on 800K/sec on a 6 disk
    array.

    (the actual performance case I saw this frequently on was a squid-1.1
    server shutting down. It would write 6 x 200Meg file, one to each of
    the 6 disks).

    I'm still not sure exactly what was happening, but the write
    performance would start of in the 4 or 5 meg/sec for the first 10 or
    so seconds, then drop to 800K/sec for the remainder of the
    data. Furious seeking occured during this time. I suspect the probem
    was that it was writing different points in the file, and because the
    window wasn't large enough, not noticing that it would have been
    better off just writing from the one point.

    Michael.

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