Re: -rt dbench scalabiltiy issue

[Nick Piggin]

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.

Anyway, I think all these problems should largely go away when path
walk fall back is improved.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/