From: john stultz <johnstul@us.ibm.com>
To: Nick Piggin <npiggin@suse.de>, "Theodore Ts'o" <tytso@mit.edu>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
Darren Hart <dvhltc@us.ibm.com>,
Clark Williams <williams@redhat.com>,
"Paul E. McKenney" <paulmck@us.ibm.com>,
Dinakar Guniguntala <dino@in.ibm.com>,
lkml <linux-kernel@vger.kernel.org>,
cmm@us.ibm.com
Subject: Re: -rt dbench scalabiltiy issue
Date: Wed, 25 Nov 2009 14:20:33 -0800 [thread overview]
Message-ID: <1259187633.3585.31.camel@localhost.localdomain> (raw)
In-Reply-To: <20091125071804.GE17484@wotan.suse.de>
On Wed, 2009-11-25 at 08:18 +0100, Nick Piggin wrote:
> On Tue, Nov 24, 2009 at 06:16:17PM -0800, john stultz wrote:
> > On Mon, 2009-11-23 at 10:06 +0100, Nick Piggin wrote:
> > > BTW. Have you tested like ext4, xfs and btrfs cases? I don't think ext3
> > > is likely to see a huge amount of scalability work, and so it will be
> > > good to give an early heads up to the more active projects...
> >
> > Yea, I need to give those a shot. I also generated the same numbers as
> > before with ext2 (all the raw numbers are in dbench-scalability dir):
> >
> > http://sr71.net/~jstultz/dbench-scalability/graphs/ext2-scalability.png
> >
> > Again, its similar to ext3, in that all the -rt variants are hitting
> > some contention issues. But I was a little surprised to see
> > 2.6.32-rc7-nick below 2.6.32-rc7 there, so generated perf data there as
> > well:
> >
> > http://sr71.net/~jstultz/dbench-scalability/perflogs/2.6.32-rc7-nick.ext2.perflog
>
> Ext2 doesn't look too bad in the -rt profiles. The block allocator is
> only taking up a couple of % of the spinlocks. Most of the contention
> is in path lookup, probably cwd dentry contention.
>
> The -nick case probably also is hitting d_lock contention more. Don't
> know why it shows up more on ext2. The stat path should be nothing
> filesystem specific outside the regular path lookup, until path lookup
> is done and we found the inode.
>
> If you're using acls or something on ext2 then lock free path walk
> might fail more often.
CC'ed Ted and Mingming as they might be interested:
Got ext4 data up:
http://sr71.net/~jstultz/dbench-scalability/graphs/ext4-scalability.png
Looks pretty similar to ext2. I'm also seeing path_get contention as
well with your patch on ext4 in the perflogs:
http://sr71.net/~jstultz/dbench-scalability/perflogs/2.6.32-rc7-nick.ext4.perflog
> Anyway, I think all these problems should largely go away when path
> walk fall back is improved.
Great, let me know when you have a rough shot at it ready for testing.
thanks
-john
next prev parent reply other threads:[~2009-11-25 22:20 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-16 20:05 -rt dbench scalabiltiy issue john stultz
2009-10-17 0:45 ` Paul E. McKenney
2009-10-17 1:03 ` john stultz
2009-10-17 1:37 ` john stultz
2009-10-17 23:06 ` Nick Piggin
2009-10-17 22:39 ` Nick Piggin
2009-11-18 1:28 ` john stultz
2009-11-18 4:25 ` Nick Piggin
2009-11-18 10:19 ` Thomas Gleixner
2009-11-18 10:52 ` Nick Piggin
2009-11-20 2:22 ` john stultz
2009-11-23 9:06 ` Nick Piggin
2009-11-25 2:16 ` john stultz
2009-11-25 7:18 ` Nick Piggin
2009-11-25 22:20 ` john stultz [this message]
2009-11-26 6:20 ` Nick Piggin
2009-12-02 1:53 ` john stultz
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=1259187633.3585.31.camel@localhost.localdomain \
--to=johnstul@us.ibm.com \
--cc=cmm@us.ibm.com \
--cc=dino@in.ibm.com \
--cc=dvhltc@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=paulmck@us.ibm.com \
--cc=tglx@linutronix.de \
--cc=tytso@mit.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.