On Mon, Jul 03, 2006 at 03:50:27PM +0200, Helge Hafting wrote:
> 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.
Thanks. You are right, the readahead logic won't affect the swap cache.
Nor will the readahead size, I guess. But to be sure, you can do one
more test on it with the following command, using the same 2.5.17-mm5:
blockdev --setra /dev/hda1 256
Please replace /dev/hda1 with the root device on your system, thanks.
Wu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
