Re: New readahead - ups and downs new test

[Helge Hafting <helgehaf@aitel.hist.no>]

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/