Messages in this thread | | | Date | Tue, 4 Jul 2006 09:26:21 +0800 | From | Fengguang Wu <> | Subject | Re: 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/
| |