All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Christoph Hellwig <hch@infradead.org>, xfs@oss.sgi.com
Subject: Re: [PATCH 2/3] [PATCH 2/3] xfs: do not use xfs_mod_incore_sb for per-cpu counters
Date: Wed, 29 Sep 2010 07:45:20 -0400	[thread overview]
Message-ID: <20100929114520.GA14048@infradead.org> (raw)
In-Reply-To: <20100929113914.GP5665@dastard>

On Wed, Sep 29, 2010 at 09:39:14PM +1000, Dave Chinner wrote:
> Not sure I like the indenting of the second line. I'd prefer the
> parameters to have a little more indent or use three lines...

That whole area needs some larger refactoring / reformatting work.
I'll see if I can ad danother patch for that.

> > +	ASSERT(field < XFS_SBS_ICOUNT || field > XFS_SBS_FDBLOCKS);
> 
> That assert will cause issues with:
> 
> > @@ -97,6 +99,8 @@ extern void	xfs_icsb_sync_counters_locke
> >  #define xfs_icsb_reinit_counters(mp)		do { } while (0)
> >  #define xfs_icsb_sync_counters(mp, flags)	do { } while (0)
> >  #define xfs_icsb_sync_counters_locked(mp, flags) do { } while (0)
> > +#define xfs_icsb_modify_counters(mp, field, delta, rsvd) \
> > +	xfs_mod_incore_sb(mp, field, delta, rsvd)
> >  #endif
> 
> UP builds. Perhaps a CONFIG_SMP only assert? Given that the per-cpu
> counter rework I'm doing doesn't have a different code path for
> UP vs SMP, it'd only be a temporary concern....

Indeed, it should be conditional.

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

  reply	other threads:[~2010-09-29 11:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-29  7:22 [PATCH 0/3] clean up superblock modification helpers Christoph Hellwig
2010-09-29  7:22 ` [PATCH 1/3] [PATCH 1/3] xfs: remove XFS_MOUNT_NO_PERCPU_SB Christoph Hellwig
2010-09-29 11:29   ` Dave Chinner
2010-09-29 11:49   ` Alex Elder
2010-09-29  7:22 ` [PATCH 2/3] [PATCH 2/3] xfs: do not use xfs_mod_incore_sb for per-cpu counters Christoph Hellwig
2010-09-29 11:39   ` Dave Chinner
2010-09-29 11:45     ` Christoph Hellwig [this message]
2010-09-29 12:06   ` Alex Elder
2010-09-29  7:22 ` [PATCH 3/3] [PATCH 3/3] xfs: do not use xfs_mod_incore_sb_batch " Christoph Hellwig
2010-09-29 11:27   ` Dave Chinner
2010-09-29 11:45     ` Christoph Hellwig
2010-09-29 12:26   ` Alex Elder
  -- strict thread matches above, loose matches on Subject: below --
2010-09-30  2:25 [PATCH 0/3] streamline superblock modification helpers V2 Christoph Hellwig
2010-09-30  2:25 ` [PATCH 2/3] [PATCH 2/3] xfs: do not use xfs_mod_incore_sb for per-cpu counters Christoph Hellwig
2010-10-01 13:56   ` Alex Elder

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=20100929114520.GA14048@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.