Date: Fri, 16 Jan 2004 15:56:45 -0800
From: Andrew Morton <akpm@osdl.org>
To: Ravi Wijayaratne <ravi_wija@yahoo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Linux Page Cache performance
Message-Id: <20040116155645.732e1fda.akpm@osdl.org>
In-Reply-To: <20040116191102.98783.qmail@web40602.mail.yahoo.com>
References: <20040116191102.98783.qmail@web40602.mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1730
Lines: 40

Ravi Wijayaratne <ravi_wija@yahoo.com> wrote:
>
> Hi All.
> 
> We are running dbench on a machine with Dual Xeon (Hyper threading 
> turned off), 1GB RAM
> and 4 Drive software RAID5. The kernel is 2.4.29-xfs 1.2. We are using 
> LVM. However
> similar test done using ext2 on a disk partiotion (no md or LVM) shows 
> 
> The throughput is find till the number of clients are Around 16. At 
> that point the throughput
> plummets about 40%. We are trying to avoid that and see how we could 
> have a consistent throughput
> perhaps sacrificing some peak performance.

Once the amount of dirty memory in the machine hits 40% of the total, the
VM starts to initiate writeout.  At 60% dirty the VM starts to deliberately
throttle the processes which are dirtying memory.

So you would expect to see extremely sudden transitions in overall
throughput at that point.  Note that if the test were to run for a longer
period of time, or if it were to leave the files behind rather than
suddenly removing them you would not notice this effect.


The probability that dbench's access patterns have any similarity to the
access patterns of the application which you care about is vanishingly
small.  The same can most probably be said of all the other off-the-shelf
benchmarks.  They're not very impressive.

You will need to analyse your application's access patterns and design a
benchmark which reasonably closely and repeatably models them.  Or, if
possible, use the live application itself.

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