Message-ID: <3C19065C.A0B375B3@zip.com.au>
Date: Thu, 13 Dec 2001 11:49:48 -0800
From: Andrew Morton <akpm@zip.com.au>
MIME-Version: 1.0
To: "Needham, Douglas" <douglas.needham@lmco.com>
CC: linux-kernel@vger.kernel.org
Subject: Re: kernel performance issues 2.4.7 -> 2.4.17-pre8
In-Reply-To: <1B7FCD9C07D3D4118FC500508BDF42E80457DFB1@emss09m02.ems.lmco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

"Needham, Douglas" wrote:
> 
> ...
>         Overall I discovered that the Red Hat modified kernel beat the stock
> kernel hands down in throughput.  Both the base Red Hat 7.2 kernel and the
> 7.2 update kernel (2.4.7-9, 2.4.9-13 respectively) had far better throughput
> than the .10, .15, .14, .16, and .17-pre8 kernels.
> 

The 60% drop in bonnie throughput going from 2.4.9 to 2.4.10 indicates that
something strange has happened.  This hasn't been observed by others.

My suspicion would be that something is wrong with the IDE tuning in your
builds of later kernels.  Please check this with `hdparm -t /dev/hda1' - make
sure that these numbers are consistent across kernel versions before you
even start.

Note: before running the hdparm test on hda1, you should mount a 4k blocksize
filesystem onto hda1.  This changes the softblocksize for the device from 1k
to 4k and, for some devices, speeds up access to the block device by
a factor of thirty.  This is some bizarro kooky brokenness which the
2.4.10 patch exposed and I'm still investigating...

For dbench, errr, just don't bother using it, unless you're using
a large number of clients - 64 or more.  At lower client numbers,
throughput is enormously dependent upon tiny changes in kernel
behaviour.   Try this:

	echo 70 64 64 256 30000 3000 80 0 0 > /proc/sys/vm/bdflush

and see the numbers go up greatly.

-
-
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/