From: David Chinner <dgc@sgi.com>
To: Timothy Shimmin <tes@sgi.com>
Cc: David Chinner <dgc@sgi.com>, xfs-dev <xfs-dev@sgi.com>,
xfs-oss <xfs@oss.sgi.com>
Subject: Re: [patch] Use atomics for iclog reference counting
Date: Fri, 15 Feb 2008 15:27:12 +1100 [thread overview]
Message-ID: <20080215042712.GY155259@sgi.com> (raw)
In-Reply-To: <47B5085D.30409@sgi.com>
On Fri, Feb 15, 2008 at 02:34:53PM +1100, Timothy Shimmin wrote:
> Dave,
>
> So a bunch of incs/decs/tests converted to the atomic versions.
> And the interesting stuff appears to be in xlog_state_release_iclog().
> Okay that looks reasonable.
> If the decrement of the cnt doesn't go down to zero then we just
> return straight away - because we won't be going to sync anything.
> And if we do go to zero then we take the lock and continue.
> Why do we test for the error/EIO beforehand now too?
> Because we don't want to return 0 if we have an error to return?
Right. Effectively it retains the same behaviour as the old code.
i.e. A call to xlog_state_release_iclog() with an elevated refcount
used to return EIO if the log had been shutdown and we need the
initial (unlocked) check to retain that behaviour.
However, this check is racy and so in the case where the last
ref goes away and we get the lock we need to check again when
we can't possibly race with a shutdown state change.
> Seems good.
>
> In the 1st 2 cases of the patch:
> > @@ -675,7 +675,7 @@ xfs_log_unmount_write(xfs_mount_t *mp)
> >
> > spin_lock(&log->l_icloglock);
> > iclog = log->l_iclog;
> > - iclog->ic_refcnt++;
> > + atomic_inc(&iclog->ic_refcnt);
> > spin_unlock(&log->l_icloglock);
> > xlog_state_want_sync(log, iclog);
> > (void) xlog_state_release_iclog(log, iclog);
> > @@ -713,7 +713,7 @@ xfs_log_unmount_write(xfs_mount_t *mp)
> > */
> > spin_lock(&log->l_icloglock);
> > iclog = log->l_iclog;
> > - iclog->ic_refcnt++;
> > + atomic_inc(&iclog->ic_refcnt);
> > spin_unlock(&log->l_icloglock);
>
> Do we still really need to take the lock etc?
log->iclog is protected by the l_icloglock as well, so the lock
needs to be retained to prevent races when reading and taking a
reference to it. IOWs, the l_icloglock still synchronises increments
and the final decrement on an iclog; we only need the atomic counter
to enable unlocked refcount decrements when the refcount is > 1.
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
next prev parent reply other threads:[~2008-02-15 4:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-21 5:30 [patch] Use atomics for iclog reference counting David Chinner
2008-01-23 5:13 ` Timothy Shimmin
2008-02-14 23:47 ` David Chinner
2008-02-15 0:24 ` David Chinner
2008-02-15 3:34 ` Timothy Shimmin
2008-02-15 4:27 ` David Chinner [this message]
2008-02-15 5:05 ` Timothy Shimmin
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=20080215042712.GY155259@sgi.com \
--to=dgc@sgi.com \
--cc=tes@sgi.com \
--cc=xfs-dev@sgi.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