lkml.org 
[lkml]   [2006]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: New readahead - ups and downs new test. Vm oddities.
    Hi Helge,

    On Mon, Jul 03, 2006 at 11:42:17PM +0200, Helge Hafting wrote:
    > I have now re-run my tests (parallel debsums and
    > bzcat+patch) this time with everything on the same device
    > so as to get competition for io.
    >
    > New and old readahead didn't make much difference this time
    > either, so it seems that my idea about readahead
    > problems were wrong. Which is good, as the new readahead
    > improves so many other things.
    >
    > Results with new readahead using one disk device:
    > Swap went up to 32M, dropped to 244k when testing ended.
    > patch timing:
    > real 6m8.451s
    > user 0m5.183s
    > sys 0m2.897s
    > debsums timing:
    > real 7m42.851s
    > user 0m21.172s
    > sys 0m13.642s
    >
    > Results with old readahead, one disk device:
    > Swap went to 32M, dropped to 244k when testing ended.
    > timings:
    > patch:
    > real 6m18.191s
    > user 0m5.226s
    > sys 0m2.724s
    > debsums:
    > real 7m49.860s
    > user 0m21.243s
    > sys 0m14.268s
    > A tiny bit slower, but very little.
    >
    >
    > No surprise that everyting is slower when using a single
    > disk instead of two.

    Thanks for all the efforts!

    > The swap difference from using two disks is striking though.
    > Nothing to do with readahead, but
    > why 32M swap when using one disk, and 244k swap when using two?
    >
    > The amount of data processed is the same either way,
    > is the VM very timing-sensitive?

    Because read/write request go for the same elevator queue I guess.

    When there are concurrent read/writes, writes will be hold back,
    giving priority to reads. So there will be more dirtied pages taking
    up your memory during the test.

    Thanks,
    Wu
    -
    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: 2006-07-04 03:28    [W:4.410 / U:0.128 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site