Messages in this thread | | | Date | Mon, 3 Jul 2006 15:50:27 +0200 | Subject | Re: New readahead - ups and downs new test | From | Helge Hafting <> |
| |
On Mon, Jul 03, 2006 at 07:55:16AM +0800, Fengguang Wu wrote: > Hi Helge, > > On Tue, Jun 27, 2006 at 03:07:16PM +0200, Helge Hafting wrote: > > I made my own little io-intensive test, that shows a case where > > performance drops. > > > > I boot the machine, and starts "debsums", a debian utility that > > checksums every file managed by debian package management. > > As soon as the machine starts swapping, I also start > > start a process that applies an mm-patch to the kernel tree, and > > times this. > > > > This patching took 1m28s with cold cache, without debsums running. > > With the 2.6.15 kernel (old readahead), and debsums running, this > > took 2m20s to complete, and 360kB in swap at the worst. > > > > With the new readahead in 2.6.17-mm3 I get 6m22s for patching, > > and 22MB in swap at the most. Runs with mm1 and mm2 were > > similiar, 5-6 minutes patching and 22MB swap. > > > > My patching clearly takes more times this way. I don't know > > if debsums improved though, it could be as simple as a fairness > > issue. Memory pressure definitely went up. > > There are a lot changes between 2.6.15 and 2.6.17-mmX. Would you use > the single 2.6.17-mm5 kernel for benchmarking? It's easy: > > - select old readahead: > echo 1 > /proc/sys/vm/readahead_ratio > > - select new readahead: > echo 50 > /proc/sys/vm/readahead_ratio > > I just tried this with 2.5.17-mm5. I did in on a faster machine (opteron cpu, but still 512MB) so don't compare with my previous test which ran on a pentium-IV. Single cpu in both cases.
Test procdure: 1. Reboot, log in through xdm 2. run vmstat 10 for swap monitoring 3. time debsums -s 4. As soon as the machine touches swap, launch time bzcat 2.6.15-mm5.bz2 | patch -p1
In either case, testing starts with 320MB free memory after boot, which debsums caching eats in about a minute and swapping starts. Then I start the patching, which finished before debsums.
Old readahed: Max swap was 700kB, but it dropped back to 244kB after 10s and stayed there. Patch timing: real 0m37.662s user 0m5.002s sys 0m2.023s debsums timing: real 5m50.333s user 0m21.127s sys 0m14.506s
New readahead: Max swap: 244kB. (On another try it jumped to 816kB and then fell back to 244kB). patch timing: real 0m40.951s user 0m5.043s sys 0m2.061s debsums timing: real 5m46.555s user 0m21.195s sys 0m13.918s
Timing and memory load seems to be almost identical this time, perhaps this is a load where the type of readahead doesn't matter.
Helge Hafting
- 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/
| |