lkml.org 
[lkml]   [2004]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Random file I/O regressions in 2.6 [patch+results]
    On Fri, May 21 2004, Nick Piggin wrote:
    > Andrew Morton wrote:
    >
    > >Open questions are:
    > >
    > >a) Why is 2.6 write coalescing so superior to 2.4?
    > >
    > >b) Why is 2.6 issuing more read requests, for less data?
    > >
    > >c) Why is Alexey seeing dissimilar results?
    > >
    >
    >
    > Interesting. I am not too familiar with 2.4's IO scheduler,
    > but 2.6's have pretty comprehensive merging systems. Could
    > that be helping, Jens? Or is 2.4 pretty equivalent?

    2.4 will give up merging faster than 2.6, elevator_linus will stop
    looking for a merge point if the sequence drops to zero. 2.6 will always
    merge. So that could explain the fewer writes.

    > What about things like maximum request size for 2.4 vs 2.6
    > for example? This is another thing that can have an impact,
    > especially for writes.

    I think that's pretty similar. Andrew didn't say what device he was
    testing on, but 2.4 ide defaults to max 64k where 2.6 defaults to 128k.

    > I'll take a guess at b, and say it could be as-iosched.c.
    > Another thing might be that 2.6 has smaller nr_requests than
    > 2.4, although you are unlikely to hid the read side limit
    > with only 16 threads if they are doing sync IO.

    Andrew, you did numbers for deadline previously as well, but no rq
    statistics there? As for nr_requests that's true, would be worth a shot
    to bump available requests in 2.6.

    --
    Jens Axboe

    -
    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 14:03    [W:2.295 / U:0.856 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site