* [PATCH] xfs: reduce lock traffic on incore sb lock
@ 2010-09-29 0:51 Dave Chinner
2010-09-29 4:04 ` Christoph Hellwig
0 siblings, 1 reply; 5+ messages in thread
From: Dave Chinner @ 2010-09-29 0:51 UTC (permalink / raw)
To: xfs
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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] xfs: reduce lock traffic on incore sb lock
2010-09-29 0:51 [PATCH] xfs: reduce lock traffic on incore sb lock Dave Chinner
@ 2010-09-29 4:04 ` Christoph Hellwig
2010-09-29 5:57 ` Dave Chinner
0 siblings, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2010-09-29 4:04 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs
On Wed, Sep 29, 2010 at 10:51:40AM +1000, Dave Chinner wrote:
> 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.
God spot of the idiocy there, but I really don't like the patch.
I've started writing a small patches series solving the issue slightly
better by cleaning up this area a bit.
After this we will never use xfs_mod_incore_sb/xfs_mod_incore_sb_batch
for the percpu counters but rather make those always go through
xfs_icsb_modify_counters. I'll need to quickly finish it up and will
send it out soon.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] xfs: reduce lock traffic on incore sb lock
2010-09-29 4:04 ` Christoph Hellwig
@ 2010-09-29 5:57 ` Dave Chinner
2010-09-29 6:13 ` Christoph Hellwig
0 siblings, 1 reply; 5+ messages in thread
From: Dave Chinner @ 2010-09-29 5:57 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
On Wed, Sep 29, 2010 at 12:04:25AM -0400, Christoph Hellwig wrote:
> On Wed, Sep 29, 2010 at 10:51:40AM +1000, Dave Chinner wrote:
> > 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.
>
> God spot of the idiocy there, but I really don't like the patch.
Fair enough - it is a rather quick hack. ;)
> I've started writing a small patches series solving the issue slightly
> better by cleaning up this area a bit.
Oh, cool. That code is quite a tangle.
> After this we will never use xfs_mod_incore_sb/xfs_mod_incore_sb_batch
> for the percpu counters but rather make those always go through
> xfs_icsb_modify_counters. I'll need to quickly finish it up and will
> send it out soon.
FWIW, I've got a prototype that converts the per-cpu counters to the
generic per-cpu counter infrastructure. It chops out almost all the
xfs_icsb_* stuff (including xfs_icsb_modify_counters()) and has a
diffstat of:
6 files changed, 317 insertions(+), 709 deletions(-)
It needs a significant cleanup of xfs_mod_incore_sb() before/after
the conversion which I haven't done yet because I haven't quite got
my new percpu_counter_test_and_add_delta() function working
correctly yet. I spotted this locking problem when testing the
patch...
That said, there's no reason why my percpu counter code needs to run
through xfs_mod_incore_sb() at all. If we have a separate path for
per-cpu counters then I can rework my code on top of that....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] xfs: reduce lock traffic on incore sb lock
2010-09-29 5:57 ` Dave Chinner
@ 2010-09-29 6:13 ` Christoph Hellwig
2010-09-29 6:28 ` Dave Chinner
0 siblings, 1 reply; 5+ messages in thread
From: Christoph Hellwig @ 2010-09-29 6:13 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs
On Wed, Sep 29, 2010 at 03:57:48PM +1000, Dave Chinner wrote:
> FWIW, I've got a prototype that converts the per-cpu counters to the
> generic per-cpu counter infrastructure. It chops out almost all the
> xfs_icsb_* stuff (including xfs_icsb_modify_counters()) and has a
> diffstat of:
Sounds good - I always throught of the balanced per-cpu counters as
infrastructure that really shouldn't sit inside XFS.
> It needs a significant cleanup of xfs_mod_incore_sb() before/after
> the conversion which I haven't done yet because I haven't quite got
> my new percpu_counter_test_and_add_delta() function working
> correctly yet. I spotted this locking problem when testing the
> patch...
>
> That said, there's no reason why my percpu counter code needs to run
> through xfs_mod_incore_sb() at all. If we have a separate path for
> per-cpu counters then I can rework my code on top of that....
We'll always need a low-level function to to the actual superblock
updates and a high-level one modifying the per-cpu counters. I don't
think the exact naming matters too much.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] xfs: reduce lock traffic on incore sb lock
2010-09-29 6:13 ` Christoph Hellwig
@ 2010-09-29 6:28 ` Dave Chinner
0 siblings, 0 replies; 5+ messages in thread
From: Dave Chinner @ 2010-09-29 6:28 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: xfs
On Wed, Sep 29, 2010 at 02:13:51AM -0400, Christoph Hellwig wrote:
> On Wed, Sep 29, 2010 at 03:57:48PM +1000, Dave Chinner wrote:
> > FWIW, I've got a prototype that converts the per-cpu counters to the
> > generic per-cpu counter infrastructure. It chops out almost all the
> > xfs_icsb_* stuff (including xfs_icsb_modify_counters()) and has a
> > diffstat of:
>
> Sounds good - I always throught of the balanced per-cpu counters as
> infrastructure that really shouldn't sit inside XFS.
The only reason I implemented them like that in the first place was
that there was no generic per-cpu counter infrastructure in
2.6.15... ;)
> > It needs a significant cleanup of xfs_mod_incore_sb() before/after
> > the conversion which I haven't done yet because I haven't quite got
> > my new percpu_counter_test_and_add_delta() function working
> > correctly yet. I spotted this locking problem when testing the
> > patch...
> >
> > That said, there's no reason why my percpu counter code needs to run
> > through xfs_mod_incore_sb() at all. If we have a separate path for
> > per-cpu counters then I can rework my code on top of that....
>
> We'll always need a low-level function to to the actual superblock
> updates and a high-level one modifying the per-cpu counters. I don't
> think the exact naming matters too much.
Agreed. I think it's probably best to wait for your cleanup patches
before reworking the counter implementation completely, though.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-09-29 6:27 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-29 0:51 [PATCH] xfs: reduce lock traffic on incore sb lock Dave Chinner
2010-09-29 4:04 ` Christoph Hellwig
2010-09-29 5:57 ` Dave Chinner
2010-09-29 6:13 ` Christoph Hellwig
2010-09-29 6:28 ` Dave Chinner
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox