xfs
[Top] [All Lists]

Re: [PATCHv2 8/10] xfs: avoid repeated pointer dereferences

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCHv2 8/10] xfs: avoid repeated pointer dereferences
From: Alex Elder <aelder@xxxxxxx>
Date: Wed, 14 Apr 2010 16:02:41 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20100412065644.GJ2493@dastard>
References: <1270852242.7840.158.camel@doink> <20100412065644.GJ2493@dastard>
Reply-to: aelder@xxxxxxx
On Mon, 2010-04-12 at 16:56 +1000, Dave Chinner wrote:
> On Fri, Apr 09, 2010 at 05:30:42PM -0500, Alex Elder wrote:
> > In xlog_find_cycle_start() use a local variable for some repeated
> > operations rather than constantly updating the memory location
> > whose address is passed in.
> 
> Won't the compiler optimise that out for us? i.e. does the dissassembly
> of the function look any better before and after this change?

I doubt it *can* optimize that.  Doing so would change
the way the function interacts semantically with the
pointed-to memory.  Still, I performed a quick check
to be sure (on an x86_64) and the compiled code really
does de-reference the pointer for both reads from and
writes to memory.

> > Signed-off-by: Alex Elder <aelder@xxxxxxx>
> > 
> > ---
> > fs/xfs/xfs_log_recover.c |   83 
> > ++++++++++++++++++++++++-----------------------
> >  fs/xfs/xfs_log_recover.c |   26 ++++++++++++++------------
> >  1 file changed, 14 insertions(+), 12 deletions(-)
> > 
> > Index: b/fs/xfs/xfs_log_recover.c
> > ===================================================================
> > --- a/fs/xfs/xfs_log_recover.c
> > +++ b/fs/xfs/xfs_log_recover.c
> > @@ -354,26 +354,28 @@ xlog_find_cycle_start(
> >  {
> >     xfs_caddr_t     offset;
> >     xfs_daddr_t     mid_blk;
> > +   xfs_daddr_t     end_blk;
> >     uint            mid_cycle;
> >     int             error;
> >  
> > -   mid_blk = BLK_AVG(first_blk, *last_blk);
> > -   while (mid_blk != first_blk && mid_blk != *last_blk) {
> > +   ASSERT(last_blk != NULL);
> > +   end_blk = *last_blk;
> 
> FWIW, there is no need for that ASSERT there - the machine will
> panic on the very next line, anyway....

Agreed.  I make a habit of stating assumptions about
passed-in arguments via assertions.  Not a big deal,
I'll take it out.

Still soliciting a reviewed-by on this one.

                                        -Alex


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