From: Dave Chinner <david@fromorbit.com>
To: xfs@oss.sgi.com
Subject: [PATCH] xfs: reduce lock traffic on incore sb lock
Date: Wed, 29 Sep 2010 10:51:40 +1000 [thread overview]
Message-ID: <1285721500-5671-1-git-send-email-david@fromorbit.com> (raw)
From: Dave Chinner <dchinner@redhat.com>
Under heavy parallel unlink workloads, the incore superblock lock is
heavily trafficed in xfs_mod_incore_sb_batch(). This is despite the
fact that the counters being modified are typically the counters
that are per-cpu and do not require the lock. IOWs, we are locking
and unlocking the superblock lock needlessly, and the result is that
it is third most heavily contended lock in the system under these
workloads.
Fix this by only locking the superblock lock when we are modifying a
counter protected by it. This completely removes the m_sb_lock from
lock_stat traces during create/remove workloads.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
---
fs/xfs/xfs_mount.c | 33 ++++++++++++++++++++++++---------
1 files changed, 24 insertions(+), 9 deletions(-)
diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 396d324..adc4ab9 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -1883,21 +1883,23 @@ xfs_mod_incore_sb(
* Either all of the specified deltas will be applied or none of
* them will. If any modified field dips below 0, then all modifications
* will be backed out and EINVAL will be returned.
+ *
+ * The @m_sb_lock is be taken and dropped on demand according to the type of
+ * counter being modified to minimise lock traffic as this can be a very hot
+ * lock.
*/
int
xfs_mod_incore_sb_batch(xfs_mount_t *mp, xfs_mod_sb_t *msb, uint nmsb, int rsvd)
{
int status=0;
xfs_mod_sb_t *msbp;
+ int locked = 0;
/*
* Loop through the array of mod structures and apply each
* individually. If any fail, then back out all those
- * which have already been applied. Do all of this within
- * the scope of the m_sb_lock so that all of the changes will
- * be atomic.
+ * which have already been applied.
*/
- spin_lock(&mp->m_sb_lock);
msbp = &msb[0];
for (msbp = &msbp[0]; msbp < (msb + nmsb); msbp++) {
/*
@@ -1911,16 +1913,22 @@ xfs_mod_incore_sb_batch(xfs_mount_t *mp, xfs_mod_sb_t *msb, uint nmsb, int rsvd)
case XFS_SBS_IFREE:
case XFS_SBS_FDBLOCKS:
if (!(mp->m_flags & XFS_MOUNT_NO_PERCPU_SB)) {
- spin_unlock(&mp->m_sb_lock);
+ if (locked) {
+ locked = 0;
+ spin_unlock(&mp->m_sb_lock);
+ }
status = xfs_icsb_modify_counters(mp,
msbp->msb_field,
msbp->msb_delta, rsvd);
- spin_lock(&mp->m_sb_lock);
break;
}
/* FALLTHROUGH */
#endif
default:
+ if (!locked) {
+ spin_lock(&mp->m_sb_lock);
+ locked = 1;
+ }
status = xfs_mod_incore_sb_unlocked(mp,
msbp->msb_field,
msbp->msb_delta, rsvd);
@@ -1949,17 +1957,23 @@ xfs_mod_incore_sb_batch(xfs_mount_t *mp, xfs_mod_sb_t *msb, uint nmsb, int rsvd)
case XFS_SBS_IFREE:
case XFS_SBS_FDBLOCKS:
if (!(mp->m_flags & XFS_MOUNT_NO_PERCPU_SB)) {
- spin_unlock(&mp->m_sb_lock);
+ if (locked) {
+ locked = 0;
+ spin_unlock(&mp->m_sb_lock);
+ }
status = xfs_icsb_modify_counters(mp,
msbp->msb_field,
-(msbp->msb_delta),
rsvd);
- spin_lock(&mp->m_sb_lock);
break;
}
/* FALLTHROUGH */
#endif
default:
+ if (!locked) {
+ spin_lock(&mp->m_sb_lock);
+ locked = 1;
+ }
status = xfs_mod_incore_sb_unlocked(mp,
msbp->msb_field,
-(msbp->msb_delta),
@@ -1970,7 +1984,8 @@ xfs_mod_incore_sb_batch(xfs_mount_t *mp, xfs_mod_sb_t *msb, uint nmsb, int rsvd)
msbp--;
}
}
- spin_unlock(&mp->m_sb_lock);
+ if (locked)
+ spin_unlock(&mp->m_sb_lock);
return status;
}
--
1.7.1
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next reply other threads:[~2010-09-29 0:50 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-29 0:51 Dave Chinner [this message]
2010-09-29 4:04 ` [PATCH] xfs: reduce lock traffic on incore sb lock Christoph Hellwig
2010-09-29 5:57 ` Dave Chinner
2010-09-29 6:13 ` Christoph Hellwig
2010-09-29 6:28 ` Dave Chinner
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=1285721500-5671-1-git-send-email-david@fromorbit.com \
--to=david@fromorbit.com \
--cc=xfs@oss.sgi.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