Re: New readahead - ups and downs new test. Vm oddities.

[Fengguang Wu]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/