From: Dave Chinner <david@fromorbit.com>
To: john stultz <johnstul@us.ibm.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Nick Piggin <npiggin@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
lkml <linux-kernel@vger.kernel.org>,
Clark Williams <williams@redhat.com>,
John Kacur <jkacur@redhat.com>
Subject: Re: Nick's vfs-scalability patches ported to 2.6.33-rt
Date: Fri, 12 Mar 2010 15:41:12 +1100 [thread overview]
Message-ID: <20100312044112.GC4732@dastard> (raw)
In-Reply-To: <1268363312.3475.85.camel@localhost.localdomain>
On Thu, Mar 11, 2010 at 07:08:32PM -0800, john stultz wrote:
> On Wed, 2010-03-10 at 04:01 -0500, Christoph Hellwig wrote:
> > On Tue, Mar 09, 2010 at 06:51:02PM -0800, john stultz wrote:
> > > So this all means that with Nick's patch set, we're no longer getting
> > > bogged down in the vfs (at least at 8-way) at all. All the contention is
> > > in the actual filesystem (ext2 in group_adjust_blocks, and ext3 in the
> > > journal and block allocation code).
> >
> > Can you check if you're running into any fs scaling limit with xfs?
>
>
> Here's the charts from some limited testing:
> http://sr71.net/~jstultz/dbench-scalability/graphs/2.6.33/xfs-dbench.png
What's the X-axis? Number of clients?
If so, I have previously tested XFS to make sure throughput is flat
out to about 1000 clients, not 8. i.e I'm not interested in peak
throughput from dbench (generally a meaningless number), I'm much
more interested in sustaining that throughput under the sorts of
loads a real fileserver would see...
> They're not great. And compared to ext3, the results are basically
> flat.
> http://sr71.net/~jstultz/dbench-scalability/graphs/2.6.33/ext3-dbench.png
>
> Now, I've not done any real xfs work before, so if there is any tuning
> needed for dbench, please let me know.
Dbench does lots of transactions which runs XFS into being log IO
bound. Make sure you have at least a 128MB log and are using
lazy-count=1 andperhaps even the logbsize=262144 mount option. but
in general it only takes 2-4 clients to reach maximum throughput on
XFS....
> The odd bit is that perf doesn't show huge overheads in the xfs runs.
> The spinlock contention is supposedly under 5%. So I'm not sure whats
> causing the numbers to be so bad.
It's bound by sleeping locks or IO. call-graph based profiles
triggered on context switches are the easiest way to find the
contending lock.
Last time I did this (around 2.6.16, IIRC) it involved patching the
kernel to put the sample point in the context switch code - can we
do that now without patching the kernel?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2010-03-12 4:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-26 5:53 Nick's vfs-scalability patches ported to 2.6.33-rt john stultz
2010-02-26 6:01 ` Nick Piggin
2010-03-03 23:31 ` john stultz
2010-03-04 3:33 ` Nick Piggin
2010-03-04 4:05 ` john stultz
2010-03-10 2:51 ` john stultz
2010-03-10 9:01 ` Christoph Hellwig
2010-03-12 3:08 ` john stultz
2010-03-12 4:41 ` Dave Chinner [this message]
2010-03-15 16:15 ` Nick Piggin
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=20100312044112.GC4732@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jkacur@redhat.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=tglx@linutronix.de \
--cc=williams@redhat.com \
/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