linux-kernel - Re: -rt dbench scalabiltiy issue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091125071804.GE17484@wotan.suse.de>
Date:	Wed, 25 Nov 2009 08:18:04 +0100
From:	Nick Piggin <npiggin@...e.de>
To:	john stultz <johnstul@...ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Darren Hart <dvhltc@...ibm.com>,
	Clark Williams <williams@...hat.com>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Dinakar Guniguntala <dino@...ibm.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: -rt dbench scalabiltiy issue

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/