mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ravi Wijayaratne <ravi_wija@yahoo.com>
To: linux-kernel@vger.kernel.org
Subject: Linux Page Cache performance
Date: Fri, 16 Jan 2004 11:11:02 -0800 (PST)	[thread overview]
Message-ID: <20040116191102.98783.qmail@web40602.mail.yahoo.com> (raw)

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.

One could argue that at the point the performance drops we are actualy 
beggining to see 
I/O requests missing page cache and going to disk. That is our current 
guess. We try to tune
the buffer age and the interval page buffer daemon runs, but had no 
effect on the curve.
So transactional meta data operations seems not be causing the bottle 
neck.

Are there any VM patches that smooths out the Page Cache dirty page 
swapping process so that we
wont see this sudden drop of through put, but could have a smoother 
transition. I ran a 
kernel profiler on the test and I dont see any dentry cache flushes or 
inode cache flushes.

Similar test done using ext2 on a disk partiotion (no md or LVM) shows 
us similar performances.
However for ext2 when we tweak the bdflush parameters in /proc 
(specifically the max age of meta
data buffers) we can push the point where the data throughput falls to 
around 40 clients. 

But we are more interested in finding out ways to solve the XFS case.

Any insights on this ?

Thanx
Ravi



=====
------------------------------
Ravi Wijayaratne

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

             reply	other threads:[~2004-01-16 19:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-16 19:11 Ravi Wijayaratne [this message]
2004-01-16 20:34 ` Mike Fedyk
2004-01-16 23:56 ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040116191102.98783.qmail@web40602.mail.yahoo.com \
    --to=ravi_wija@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®