All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/3] xfs: replace do_mod with native operations
Date: Fri, 8 Jun 2018 08:23:12 +1000	[thread overview]
Message-ID: <20180607222312.GT10363@dastard> (raw)
In-Reply-To: <20180607114204.GD7798@bfoster>

On Thu, Jun 07, 2018 at 07:42:05AM -0400, Brian Foster wrote:
> On Thu, Jun 07, 2018 at 03:27:50PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> > 
> > do_mod() is a hold-over from when we have different sizes for file
> > offsets and and other internal values for 40 bit XFS filesystems.
> > Hence depending on build flags variables passed to do_mod() could
> > change size. We no longer support those small format filesystems and
> > hence everything is of fixed size theses days, even on 32 bit
> > platforms.
> > 
> > As such, we can convert all the do_mod() callers to platform
> > optimised modulus operations as defined by linux/math64.h.
> > Individual conversions depend on the types of variables being used.
> > 
> > Signed-Off-By: Dave Chinner <dchinner@redhat.com>

....

> > diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c
> > index 80bbfe604ce0..776502a5dcb7 100644
> > --- a/fs/xfs/xfs_rtalloc.c
> > +++ b/fs/xfs/xfs_rtalloc.c
> ...
> > @@ -1262,8 +1266,11 @@ xfs_rtpick_extent(
> >  		resid = seq - (1ULL << log2);
> >  		b = (mp->m_sb.sb_rextents * ((resid << 1) + 1ULL)) >>
> >  		    (log2 + 1);
> > -		if (b >= mp->m_sb.sb_rextents)
> > -			b = do_mod(b, mp->m_sb.sb_rextents);
> > +		if (b >= mp->m_sb.sb_rextents) {
> > +			xfs_rtblock_t mod;
> > +			div64_u64_rem(b, mp->m_sb.sb_rextents, &mod);
> > +			b = mod;
> > +		}
> 
> Shouldn't we be able to do 'div64_u64_rem(b, mp->m_sb.sb_rextents, &b)'
> here? Otherwise looks fine:

Yeah, I think we can. IIRC I was looking at various implementations
and took the template from something like dm_sector_div64() because
"obviously correct" :)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2018-06-07 22:23 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07  5:27 [PATCH 0/3] xfs: minor cleanups Dave Chinner
2018-06-07  5:27 ` [PATCH 1/3] xfs: move various type verifiers to common file Dave Chinner
2018-06-07 11:41   ` Brian Foster
2018-06-07 15:23   ` Darrick J. Wong
2018-06-08  6:24   ` Christoph Hellwig
2018-06-07  5:27 ` [PATCH 2/3] xfs: replace do_mod with native operations Dave Chinner
2018-06-07 11:42   ` Brian Foster
2018-06-07 16:01     ` Darrick J. Wong
2018-06-07 22:23     ` Dave Chinner [this message]
2018-06-07 15:54   ` Darrick J. Wong
2018-06-07 22:28     ` Dave Chinner
2018-06-08  0:43   ` [PATCH 2/3 V2] " Dave Chinner
2018-06-08  6:19     ` Christoph Hellwig
2018-06-08  7:31       ` Dave Chinner
2018-06-07  5:27 ` [PATCH 3/3] xfs: clean up MIN/MAX Dave Chinner
2018-06-07 11:42   ` Brian Foster
2018-06-08  6:23   ` Christoph Hellwig

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=20180607222312.GT10363@dastard \
    --to=david@fromorbit.com \
    --cc=bfoster@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    /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.