From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 03/16] [RFC] xfs: use generic per-cpu counter infrastructure
Date: Mon, 8 Nov 2010 07:13:22 -0500 [thread overview]
Message-ID: <20101108121322.GA3023@infradead.org> (raw)
In-Reply-To: <1289206519-18377-4-git-send-email-david@fromorbit.com>
On Mon, Nov 08, 2010 at 07:55:06PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> XFS has a per-cpu counter implementation for in-core superblock
> counters that pre-dated the generic implementation. It is complex
> and baroque as it is tailored directly to the needs of ENOSPC
> detection. Implement the complex accurate-compare-and-add
> calculation in the generic per-cpu counter code and convert the
> XFS counters to use the much simpler generic counter code.
>
> Passes xfsqa on SMP system.
Some mostly cosmetic comments below. I haven't looked at the more
hairy bits like the changes to the generic percpu code and the
reservation handling yet.
> 1. kill the no-per-cpu-counter mode?
already done.
> 3. do we need to factor xfs_mod_sb_incore()?
Doesn't exist anymore.
> - xfs_icsb_sync_counters(mp, XFS_ICSB_LAZY_COUNT);
> + xfs_icsb_sync_counters(mp);
> spin_lock(&mp->m_sb_lock);
Can be moved inside the lock and use the unlocked version, too.
> +static inline int
> +xfs_icsb_add(
> + struct xfs_mount *mp,
> + int counter,
> + int64_t delta,
> + int64_t threshold)
> +{
> + int ret;
> +
> + ret = percpu_counter_add_unless_lt(&mp->m_icsb[counter], delta,
> + threshold);
> + if (ret < 0)
> + return -ENOSPC;
> + return 0;
> +}
> +
> +static inline void
> +xfs_icsb_set(
> + struct xfs_mount *mp,
> + int counter,
> + int64_t value)
> +{
> + percpu_counter_set(&mp->m_icsb[counter], value);
> +}
> +
> +static inline int64_t
> +xfs_icsb_sum(
> + struct xfs_mount *mp,
> + int counter)
> +{
> + return percpu_counter_sum_positive(&mp->m_icsb[counter]);
> +}
> +
> +static inline int64_t
> +xfs_icsb_read(
> + struct xfs_mount *mp,
> + int counter)
> +{
> + return percpu_counter_read_positive(&mp->m_icsb[counter]);
> +}
I would just opencode all these helpers in their callers. There's
generally just one caller of each, which iterates over the three
counters anyway.
> +int
> +xfs_icsb_modify_counters(
> + xfs_mount_t *mp,
> + xfs_sb_field_t field,
> + int64_t delta,
> + int rsvd)
I can't see the point of keeping this multiplexer. The inode counts
are handled entirely different from the block count, so they should
have separate functions.
> +{
> + int64_t lcounter;
> + int64_t res_used;
> + int ret = 0;
> +
> +
> + switch (field) {
> + case XFS_SBS_ICOUNT:
> + ret = xfs_icsb_add(mp, XFS_ICSB_ICOUNT, delta, 0);
> + if (ret < 0) {
> + ASSERT(0);
> + return XFS_ERROR(EINVAL);
> + }
> + return 0;
> +
> + case XFS_SBS_IFREE:
> + ret = xfs_icsb_add(mp, XFS_ICSB_IFREE, delta, 0);
> + if (ret < 0) {
> + ASSERT(0);
> + return XFS_ERROR(EINVAL);
> + }
> + return 0;
If you're keeping a common helper for both inode counts this can be
simplified by sharing the code and just passing on the field instead
of having two cases.
> + struct percpu_counter m_icsb[XFS_ICSB_MAX];
I wonder if there's all that much of a point in keeping the array.
We basically only use the fact it's an array for the init/destroy
code. Maybe it would be a tad cleaner to just have three separate
percpu counters.
> +static inline void
> +xfs_icsb_sync_counters(
> + struct xfs_mount *mp)
> +{
> + spin_lock(&mp->m_sb_lock);
> + xfs_icsb_sync_counters_locked(mp);
> + spin_unlock(&mp->m_sb_lock);
> +}
There's only one callers of this left after my comment above is
addressed. I'd just make xfs_icsb_sync_counters the locked version,
throw in an assert_spin_locked and have the one remaining caller
take the lock opencoded as well.
> --- a/include/linux/percpu_counter.h
> +++ b/include/linux/percpu_counter.h
> @@ -41,6 +41,8 @@ void percpu_counter_set(struct percpu_counter *fbc, s64 amount);
> void __percpu_counter_add(struct percpu_counter *fbc, s64 amount, s32 batch);
> s64 __percpu_counter_sum(struct percpu_counter *fbc);
> int percpu_counter_compare(struct percpu_counter *fbc, s64 rhs);
> +int percpu_counter_add_unless_lt(struct percpu_counter *fbc, s64 amount,
> + s64 threshold);
>
> static inline void percpu_counter_add(struct percpu_counter *fbc, s64 amount)
> {
> @@ -153,6 +155,20 @@ static inline int percpu_counter_initialized(struct percpu_counter *fbc)
> return 1;
> }
>
> +static inline int percpu_counter_test_and_add_delta(struct percpu_counter *fbc, s64 delta)
This doesn't match the function provided for CONFIG_SMP.
> +/**
> + *
spurious line.
> +int percpu_counter_add_unless_lt(struct percpu_counter *fbc, s64 amount, s64
> +threshold)
too long line
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-11-08 12:11 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-08 8:55 [PATCH 00/16] xfs: current patch stack for 2.6.38 window Dave Chinner
2010-11-08 8:55 ` [PATCH 01/16] xfs: fix per-ag reference counting in inode reclaim tree walking Dave Chinner
2010-11-08 9:23 ` Christoph Hellwig
2010-11-08 8:55 ` [PATCH 02/16] xfs: move delayed write buffer trace Dave Chinner
2010-11-08 9:24 ` Christoph Hellwig
2010-11-08 8:55 ` [PATCH 03/16] [RFC] xfs: use generic per-cpu counter infrastructure Dave Chinner
2010-11-08 12:13 ` Christoph Hellwig [this message]
2010-11-09 0:20 ` Dave Chinner
2010-11-08 8:55 ` [PATCH 04/16] xfs: dynamic speculative EOF preallocation Dave Chinner
2010-11-08 11:43 ` Christoph Hellwig
2010-11-09 0:08 ` Dave Chinner
2010-11-08 8:55 ` [PATCH 05/16] xfs: don't truncate prealloc from frequently accessed inodes Dave Chinner
2010-11-08 11:36 ` Christoph Hellwig
2010-11-08 23:56 ` Dave Chinner
2010-11-08 8:55 ` [PATCH 06/16] patch xfs-inode-hash-fake Dave Chinner
2010-11-08 9:19 ` Christoph Hellwig
2010-11-08 8:55 ` [PATCH 07/16] xfs: convert inode cache lookups to use RCU locking Dave Chinner
2010-11-08 23:09 ` Christoph Hellwig
2010-11-09 0:24 ` Dave Chinner
2010-11-09 3:36 ` Paul E. McKenney
2010-11-09 5:04 ` Dave Chinner
2010-11-10 5:12 ` Paul E. McKenney
2010-11-10 6:20 ` Dave Chinner
2010-11-08 8:55 ` [PATCH 08/16] xfs: convert pag_ici_lock to a spin lock Dave Chinner
2010-11-08 23:10 ` Christoph Hellwig
2010-11-08 8:55 ` [PATCH 09/16] xfs: convert xfsbud shrinker to a per-buftarg shrinker Dave Chinner
2010-11-08 8:55 ` [PATCH 10/16] xfs: add a lru to the XFS buffer cache Dave Chinner
2010-11-08 23:19 ` Christoph Hellwig
2010-11-08 23:45 ` Dave Chinner
2010-11-08 8:55 ` [PATCH 11/16] xfs: connect up buffer reclaim priority hooks Dave Chinner
2010-11-08 11:25 ` Christoph Hellwig
2010-11-08 23:50 ` Dave Chinner
2010-11-08 8:55 ` [PATCH 12/16] xfs: bulk AIL insertion during transaction commit Dave Chinner
2010-11-08 8:55 ` [PATCH 13/16] xfs: reduce the number of AIL push wakeups Dave Chinner
2010-11-08 11:32 ` Christoph Hellwig
2010-11-08 23:51 ` Dave Chinner
2010-11-08 8:55 ` [PATCH 14/16] xfs: remove all the inodes on a buffer from the AIL in bulk Dave Chinner
2010-11-08 8:55 ` [PATCH 15/16] xfs: only run xfs_error_test if error injection is active Dave Chinner
2010-11-08 11:33 ` Christoph Hellwig
2010-11-08 8:55 ` [PATCH 16/16] xfs: make xlog_space_left() independent of the grant lock Dave Chinner
2010-11-08 14:17 ` [PATCH 00/16] xfs: current patch stack for 2.6.38 window Christoph Hellwig
2010-11-09 0:21 ` 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=20101108121322.GA3023@infradead.org \
--to=hch@infradead.org \
--cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.