From: Bob Peterson <rpeterso@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [GFS2 PATCH 0/3] GFS2: Reduce contention on gfs2_log_lock
Date: Wed, 25 Jan 2017 14:58:47 -0500 [thread overview]
Message-ID: <20170125195850.32320-1-rpeterso@redhat.com> (raw)
Simultaneous writes from a single node were very slow due to
contention for the gfs2_log_lock. This lock is used to protect the
journaled data and metadata buffer lists, and the list headers in the
superblock that hold pointers to them. The log_lock is used whenever
a metadata block is added to a transaction (which happens a lot).
The problem is, the vast majority of times this call is made (e.g.
to function gfs2_trans_add_meta) the metadata buffer is already in
the log (in the superblock's list), and therefore, the locking is not
needed, and causes unnecessary contention. Since it's a spin_lock,
this consumes lots of CPU time. The more simultaneous writers, the
more CPUs are contending for the spin_lock. In other words, they
wait for permission to add a buffer to the journal, when in fact,
most of the time, the buffer is already there.
This is a series of patches designed to reduce contention on the
gfs2_log_lock. It works by not locking the log lock unless it
determines the metadata block is not already in the transaction.
It can safely do that by checking the value in the bd while the
buffer_head is locked.
IMPORTANT: This patch hinges on a lock inversion: I switched the
order of the gfs2_log_lock and the ail lock throughout gfs2.
Without doing that, you can't provide adequate protection of the
lists in the superblock without holding the gfs2_log_lock for long
periods of time. There were other places where the log_lock was
locked unnecessarily, and I've tried to eliminate them.
Also note that this patch tries to separate the log_lock, which
protects the sd_log_le_buf (and similar) and its constituent
bd_list members, and the sd_ail_lock which protects the active
items lists.
Also, prior to this patch, the allocation of new gfs2_bufdata items
was protected by the gfs2_log_lock. Now it's entirely protected by
lock_buffer in a new function, lock_bh_get_bd.
I consider these experimental patches for now; so not the final
solution. Testing is still ongoing, but positive. I'm just looking
for feedback at this point.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
---
Bob Peterson (3):
GFS2: Switch tr_touched to flag in transaction
GFS2: Inline function meta_lo_add
GFS2: Reduce contention on gfs2_log_lock
fs/gfs2/aops.c | 23 ++++--------
fs/gfs2/glops.c | 4 +--
fs/gfs2/incore.h | 10 ++++--
fs/gfs2/log.c | 12 +++----
fs/gfs2/lops.c | 3 +-
fs/gfs2/meta_io.c | 17 +++++----
fs/gfs2/trans.c | 103 ++++++++++++++++++++++++------------------------------
7 files changed, 80 insertions(+), 92 deletions(-)
--
2.9.3
next reply other threads:[~2017-01-25 19:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-25 19:58 Bob Peterson [this message]
2017-01-25 19:58 ` [Cluster-devel] [GFS2 PATCH 1/3] GFS2: Switch tr_touched to flag in transaction Bob Peterson
2017-01-26 10:59 ` Steven Whitehouse
2017-01-25 19:58 ` [Cluster-devel] [GFS2 PATCH 2/3] GFS2: Inline function meta_lo_add Bob Peterson
2017-01-26 11:07 ` Steven Whitehouse
2017-01-25 19:58 ` [Cluster-devel] [GFS2 PATCH 3/3] GFS2: Reduce contention on gfs2_log_lock Bob Peterson
2017-01-26 11:39 ` Steven Whitehouse
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=20170125195850.32320-1-rpeterso@redhat.com \
--to=rpeterso@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).