lkml.org 
[lkml]   [2003]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: RFC on io-stalls patch
    On Tue, Jul 15, 2003 at 08:08:57AM +0200, Jens Axboe wrote:
    > I don't see the 31% slowdown. We complete less tar loads, but only
    > because there's less time to complete them in. Well almost, as you list

    I see, so I agree the writer wrote at almost the same speed.

    > I see tar making progress, how could it be stopped?

    I didn't know the load was stopped after 249 seconds, I could imagine it,
    sorry. I was probably obfuscated by the two severe problems the code had
    that could lead to what I was expecting with more readers running
    simultanously.

    So those numbers sounds perfectly reproducible with a fixed patch too.

    At the light of this latest info you convinced me you were right, I
    probably understimated the value of the separated queues when I dropped
    it to simplify the code.

    I guess waiting the batch_sectors before getting a request for a read
    was allowing another writer to get it first because the other writer was
    already queued in the FIFO waitqueue when the writer got in. that might
    explain the difference, the reserved requests avoid the reader to wait
    for batch_sectors twice (that translates in 1/4 of the queue less to
    wait at every I/O plus the obvious minor saving in less schedules and
    waitqueue registration).

    It'll be great to give another boost to the elevator-lowlatency thanks
    to this feature.

    thanks,

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

    \
     
     \ /
      Last update: 2005-03-22 13:46    [W:8.058 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site