All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Becker <Joel.Becker@oracle.com>
To: "Theodore Ts'o" <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com, Keith Maanthey <kmannth@us.ibm.com>,
	John Stultz <johnstul@us.ibm.com>,
	Eric Whitney <eric.whitney@hp.com>
Subject: Re: [Ocfs2-devel] [PATCH, RFC 0/3] *** SUBJECT HERE ***
Date: Tue, 3 Aug 2010 12:07:03 -0700	[thread overview]
Message-ID: <20100803190703.GA15416@mail.oracle.com> (raw)
In-Reply-To: <1280851315-9167-1-git-send-email-tytso@mit.edu>

On Tue, Aug 03, 2010 at 12:01:52PM -0400, Theodore Ts'o wrote:
> The first patch in this patch series hasn't changed since when I had
> last posted it, but I'm including it again for the benefit of the folks
> on ocfs2-dev.

	Thanks!

> Thanks to some work done by Eric Whitney, when he accidentally ran the
> command "mkfs.ext4 -t xfs", and created a ext4 file system without a
> journal, it appears that main scalability bottleneck for ext4 is in the
> jbd2 layer.

	I'm certain, as you've surmised, that a lot of this affects
ocfs2 as well.  jbd2 improvements make both filesystems better.
	
> This patch series removes all exclusive spinlocks when starting and
> stopping jbd2 handles, which should improve things even more.  Since
> OCFS2 uses the jbd2 layer, and the second patch in this patch series
> touches ocfs2 a wee bit, I'd appreciate it if you could take a look and
> let me know what you think.  Hopefully, this should also improve OCFS2's
> scalability.

	The atomic changes make absolute sense.  Ack on them.  I had two
reactions to the rwlock: first, a lot of your rwlock changes are on
the write_lock() side.  You get journal start/stop parallelized, but
what about all the underlying access/dirty/commit paths?  Second,
rwlocks are known to behave worse than spinlocks when they ping the
cache line across CPUs.
	That said, I have a hunch that you've tested both of the above
concerns.  You mention 48 core systems, and clearly if cachelines were
going to be a problem, you would have noticed.  So if the rwlock changes
are faster on 48 core than the spinlocks, I say ack ack ack.
	From the ocfs2 perspective, the code is perfectly safe, and any
speedup you see on ext4 ought to be mirrored on ocfs2.

Joel

-- 

A good programming language should have features that make the
kind of people who use the phrase "software engineering" shake
their heads disapprovingly.
	- Paul Graham

Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127

WARNING: multiple messages have this Message-ID (diff)
From: Joel Becker <Joel.Becker@oracle.com>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Ext4 Developers List <linux-ext4@vger.kernel.org>,
	ocfs2-devel@oss.oracle.com, Keith Maanthey <kmannth@us.ibm.com>,
	John Stultz <johnstul@us.ibm.com>,
	Eric Whitney <eric.whitney@hp.com>
Subject: [Ocfs2-devel] [PATCH, RFC 0/3] *** SUBJECT HERE ***
Date: Tue, 3 Aug 2010 12:07:03 -0700	[thread overview]
Message-ID: <20100803190703.GA15416@mail.oracle.com> (raw)
In-Reply-To: <1280851315-9167-1-git-send-email-tytso@mit.edu>

On Tue, Aug 03, 2010 at 12:01:52PM -0400, Theodore Ts'o wrote:
> The first patch in this patch series hasn't changed since when I had
> last posted it, but I'm including it again for the benefit of the folks
> on ocfs2-dev.

	Thanks!

> Thanks to some work done by Eric Whitney, when he accidentally ran the
> command "mkfs.ext4 -t xfs", and created a ext4 file system without a
> journal, it appears that main scalability bottleneck for ext4 is in the
> jbd2 layer.

	I'm certain, as you've surmised, that a lot of this affects
ocfs2 as well.  jbd2 improvements make both filesystems better.
	
> This patch series removes all exclusive spinlocks when starting and
> stopping jbd2 handles, which should improve things even more.  Since
> OCFS2 uses the jbd2 layer, and the second patch in this patch series
> touches ocfs2 a wee bit, I'd appreciate it if you could take a look and
> let me know what you think.  Hopefully, this should also improve OCFS2's
> scalability.

	The atomic changes make absolute sense.  Ack on them.  I had two
reactions to the rwlock: first, a lot of your rwlock changes are on
the write_lock() side.  You get journal start/stop parallelized, but
what about all the underlying access/dirty/commit paths?  Second,
rwlocks are known to behave worse than spinlocks when they ping the
cache line across CPUs.
	That said, I have a hunch that you've tested both of the above
concerns.  You mention 48 core systems, and clearly if cachelines were
going to be a problem, you would have noticed.  So if the rwlock changes
are faster on 48 core than the spinlocks, I say ack ack ack.
	From the ocfs2 perspective, the code is perfectly safe, and any
speedup you see on ext4 ought to be mirrored on ocfs2.

Joel

-- 

A good programming language should have features that make the
kind of people who use the phrase "software engineering" shake
their heads disapprovingly.
	- Paul Graham

Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker at oracle.com
Phone: (650) 506-8127

  parent reply	other threads:[~2010-08-03 19:08 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-03 16:01 [PATCH, RFC 0/3] *** SUBJECT HERE *** Theodore Ts'o
2010-08-03 16:01 ` [Ocfs2-devel] " Theodore Ts'o
2010-08-03 16:01 ` [PATCH, RFC 1/3] jbd2: Use atomic variables to avoid taking t_handle_lock in jbd2_journal_stop Theodore Ts'o
2010-08-03 16:01   ` [Ocfs2-devel] " Theodore Ts'o
2010-08-03 16:01 ` [PATCH, RFC 2/3] jbd2: Change j_state_lock to be a rwlock_t Theodore Ts'o
2010-08-03 16:01   ` [Ocfs2-devel] " Theodore Ts'o
2010-08-04  0:08   ` Ted Ts'o
2010-08-04  0:08     ` [Ocfs2-devel] " Ted Ts'o
2010-08-03 16:01 ` [PATCH, RFC 3/3] jbd2: Remove t_handle_lock from start_this_handle() Theodore Ts'o
2010-08-03 16:01   ` [Ocfs2-devel] " Theodore Ts'o
2010-08-03 19:07 ` Joel Becker [this message]
2010-08-03 19:07   ` [Ocfs2-devel] [PATCH, RFC 0/3] *** SUBJECT HERE *** Joel Becker
2010-08-03 20:07   ` Ted Ts'o
2010-08-03 20:07     ` Ted Ts'o
2010-08-03 21:19     ` Joel Becker
2010-08-03 21:19       ` Joel Becker
2010-08-03 22:57       ` Ted Ts'o
2010-08-03 22:57         ` Ted Ts'o
2010-08-10  3:40 ` [PATCH, RFC 0/3] *** SUBJECT HERE *** (ext4 scalability patches) Eric Whitney
2010-08-10  3:40   ` [Ocfs2-devel] " Eric Whitney
2010-08-11 21:08   ` Ted Ts'o
2010-08-11 21:08     ` [Ocfs2-devel] " Ted Ts'o

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=20100803190703.GA15416@mail.oracle.com \
    --to=joel.becker@oracle.com \
    --cc=eric.whitney@hp.com \
    --cc=johnstul@us.ibm.com \
    --cc=kmannth@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=tytso@mit.edu \
    /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.