xfs
[Top] [All Lists]

Re: [PATCH 6/7] xfs: replace xfs_mod_incore_sb_batched

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH 6/7] xfs: replace xfs_mod_incore_sb_batched
From: Brian Foster <bfoster@xxxxxxxxxx>
Date: Thu, 5 Feb 2015 09:27:07 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150205141954.GA18047@xxxxxxxxxxxxx>
References: <1423083249-27493-1-git-send-email-david@xxxxxxxxxxxxx> <1423083249-27493-7-git-send-email-david@xxxxxxxxxxxxx> <20150205141044.GH31625@xxxxxxxxxxxxxx> <20150205141954.GA18047@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.23 (2014-03-12)
On Thu, Feb 05, 2015 at 06:19:54AM -0800, Christoph Hellwig wrote:
> On Thu, Feb 05, 2015 at 09:10:44AM -0500, Brian Foster wrote:
> > >   /* apply remaining deltas */
> > > + spin_lock(&mp->m_sb_lock);
> > >   if (rtxdelta) {
> > > -         error = xfs_mod_frextents(mp, rtxdelta);
> > > +         error = xfs_sb_mod64(&mp->m_sb.sb_frextents, rtxdelta);
> > 
> > Any reason why we don't continue to use the xfs_mod_frextents() function
> > introduced in the previous patch? Seems like we should be consistent one
> > way or the other.
> 
> We're already under the sb_lock and would need another lock roundtrip to
> avoid a deadlock in that case.  But mit might be worth to simply make
> the real time extent counter a percpu one to behave similar to the other
> counters that can be manipulated outside of the transaction commit code.
> 

Ah, thanks... missed that the lock was taken there. This one looks fine
to me as well:

Reviewed-by: Brian Foster <bfoster@xxxxxxxxxx>

> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs

<Prev in Thread] Current Thread [Next in Thread>