linux-ext4 - Re: [PATCH] jbd2: Use atomic variables to avoid taking t_handle_lock in jbd2_journal

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: <1280790152.3966.14.camel@localhost.localdomain>
Date:	Mon, 02 Aug 2010 16:02:32 -0700
From:	john stultz <johnstul@...ibm.com>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Keith Maanthey <kmannth@...ibm.com>,
	Eric Whitney <eric.whitney@...com>
Subject: Re: [PATCH] jbd2: Use atomic variables to avoid taking
 t_handle_lock in jbd2_journal_stop

On Mon, 2010-08-02 at 08:48 -0400, Theodore Ts'o wrote:
> By using an atomic_t for t_updates and t_outstanding credits, this
> should allow us to not need to take transaction t_handle_lock in
> jbd2_journal_stop().
> 
> Signed-off-by: "Theodore Ts'o" <tytso@....edu>
> Cc: John Stultz <johnstul@...ibm.com>
> Cc: Keith Maanthey <kmannth@...ibm.com>
> Cc: Eric Whitney <eric.whitney@...com>
> ---
> 
> It would be interesting to get some quick performance tests with and
> without this patch on (a) dbench w/ PREEMPT-RT, (b) Keith's 8-way, and
> (c) Eric's 48-core machine.  I have some other ideas for how to improve
> things in start_this_handle(), but they're going to be tricker, and I
> want to do some hard testing using xfstests on a big machine to make
> sure this is really safe before I keep going.  This has passed light
> testing, but I haven't had a chance to do stress tests on a large SMP
> machine yet.  That'll come later this week, hopefully.

So sort of quick and dirty numbers. I'd not trust them too far, but
gives a basic feel for how things are doing.

So this is dbench #s on an 8-core blade:
				1	2	4	8
vfs+j_state lock		401	724	1203	1142
vfs+j_state lock+atomic		408	745	1266	1263
no vfs, no ext4 patches		410	711	1071	434
no vfs, j_state lock		411	714	1113	806
no vfs, j_state lock+atomic	411	723	1149	816

Graphically:
http://sr71.net/~jstultz/dbench-scalability/graphs/2.6.33-rt-ext4-atomic/preempt-rt-ext4-dbench.png


So the vfs-scalability patchset was reverted from -rt due to some
difficult stability issues that were seen in testing. Hopefully we'll be
able to sort them out when -rt moves forward to 2.6.35 or later and we
can use Nick's more cleaned up current queue rather then my poor forward
port of his work from last September.

Anyway, I wanted to show how this patch affects dbench numbers on -rt
both with and without the vfs-scalability patches and the earlier
j_state lock change.

The vfs versions use the 2.6.33-rt23 kernel, and the non vfs use the
2.6.33-rt26 kernel.

>>From these numbers, it looks like the atomic variables are a minor
improvement for -rt, but the improvement isn't as drastic as the earlier
j_state lock change, or the vfs scalability patchset.

Didn't run into any troubles with this patch in my testing, but again,
it was a fairly quick set of runs.

thanks
-john



--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html