[lkml]   [2006]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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.

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