From: Alex Elder <aelder@sgi.com>
To: wkendall@sgi.com
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH v2 7/9] xfsrestore: make node lookup more efficient
Date: Mon, 15 Nov 2010 14:38:37 -0600 [thread overview]
Message-ID: <1289853517.2199.226.camel@doink> (raw)
In-Reply-To: <20101105163644.371326494@sgi.com>
On Fri, 2010-11-05 at 11:35 -0500, wkendall@sgi.com wrote:
> plain text document attachment (window_lookup_performance)
> When converting an nh_t to a segment index and relative node index,
> use shift and bitwise-and instead of division and modulo. Results show
> this is about 50% faster than the current method.
>
>
> Signed-off-by: Bill Kendall <wkendall@sgi.com>
I have a few comments below. They are suggestions and
don't indicate that I've found any real problems in your
code. If you think that updating things in response to
my suggestions is warranted, but want to do it later (as
a separate change) that's OK with me.
Reviewed-by: Alex Elder <aelder@sgi.com>
> ---
> restore/node.c | 150 ++++++++++++++++++++++++++++-----------------------------
> restore/win.c | 36 +++----------
> restore/win.h | 6 +-
> 3 files changed, 87 insertions(+), 105 deletions(-)
>
> Index: xfsdump-kernel.org/restore/node.c
> ===================================================================
> --- xfsdump-kernel.org.orig/restore/node.c
> +++ xfsdump-kernel.org/restore/node.c
. . .
> @@ -173,6 +166,12 @@ typedef struct node_hdr node_hdr_t;
> static node_hdr_t *node_hdrp;
> static intgen_t node_fd;
The following forward declarations could be eliminated
if you just move their definitions up in the file.
> +/* forward declarations of locally defined static functions ******************/
> +static inline size_t nh2segix( nh_t nh );
> +static inline nh_t nh2relnix( nh_t nh );
> +static inline void node_map_internal( nh_t nh, void **pp );
> +static inline void node_unmap_internal( nh_t nh, void **pp, bool_t freepr );
> +
> /* ARGSUSED */
> bool_t
> node_init( intgen_t fd,
. . .
> @@ -281,6 +280,8 @@ node_init( intgen_t fd,
> winmapmax = min( vmsz / segsz, max_segments );
> }
>
> + relnixmask = nodesperseg - 1;
> +
Is nodesperseg guaranteed to be a power of 2? It may
be, but it's not obvious to me from glancing at this
block of code.
> /* map the abstraction header
> */
> ASSERT( ( NODE_HDRSZ & pgmask ) == 0 );
. . .
> void
> Index: xfsdump-kernel.org/restore/win.c
> ===================================================================
> --- xfsdump-kernel.org.orig/restore/win.c
> +++ xfsdump-kernel.org/restore/win.c
> @@ -177,31 +177,16 @@ win_init( intgen_t fd,
> }
>
> void
> -win_map( off64_t off, void **pp )
> +win_map( size_t segix, void **pp )
It might be nice to have a segix_t or something.
The point being that what you are passing in here
is an index value (not a size), which is computed
from a node handle by figuring out which segment
that node handle resides in.
I was a little puzzled that nh2segix() took a
node handle and returned a size_t.
Similarly, a relnix appears to be an index
value within a segment; an integral typedef
could be used to clear that up. (and make
it clear it's different from just a nh_t).
Again, this suggestion comes out of my
not understanding the return type of
nh2relnix().
> {
> - size_t offwithinseg;
> - size_t segix;
> off64_t segoff;
> win_t *winp;
>
> CRITICAL_BEGIN();
>
> - /* calculate offset within segment
> - */
> - offwithinseg = ( size_t )( off % ( off64_t )tranp->t_segsz );
> -
> - /* calculate segment index
> - */
> - segix = (size_t)( off / ( off64_t )tranp->t_segsz );
> -
> - /* calculate offset of segment
> - */
> - segoff = off - ( off64_t )offwithinseg;
> -
> #ifdef TREE_DEBUG
> mlog(MLOG_DEBUG | MLOG_TREE | MLOG_NOLOCK,
> - "win_map(off=%lld,addr=%x): off within = %llu, segoff = %lld\n",
> - off, pp, offwithinseg, segoff);
> + "win_map(segix=%lu,addr=%p)\n", segix, pp);
> #endif
> /* resize the array if necessary */
> if ( segix >= tranp->t_segmaplen )
. . .
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-11-15 20:37 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 16:35 [PATCH v2 0/9] xfsrestore dirent limitations and scaling issues wkendall
2010-11-05 16:35 ` [PATCH v2 1/9] xfsrestore: turn off NODECHK wkendall
2010-11-12 23:23 ` Alex Elder
2010-11-05 16:35 ` [PATCH v2 2/9] xfsrestore: change nrh_t from 32 to 64 bits wkendall
2010-11-12 23:24 ` Alex Elder
2010-11-05 16:35 ` [PATCH v2 3/9] xfsrestore: cache path lookups wkendall
2010-11-12 23:25 ` Alex Elder
2010-11-05 16:35 ` [PATCH v2 4/9] xfsrestore: mmap dirent names for faster lookups wkendall
2010-11-12 23:25 ` Alex Elder
2010-11-15 21:51 ` Bill Kendall
2010-11-05 16:35 ` [PATCH v2 5/9] xfsrestore: cleanup node allocation wkendall
2010-11-15 20:38 ` Alex Elder
2010-11-15 21:36 ` Bill Kendall
2010-11-05 16:35 ` [PATCH v2 6/9] xfsrestore: fix node table setup wkendall
2010-11-15 20:38 ` Alex Elder
2010-11-15 21:30 ` Bill Kendall
2010-11-05 16:35 ` [PATCH v2 7/9] xfsrestore: make node lookup more efficient wkendall
2010-11-15 20:38 ` Alex Elder [this message]
2010-11-15 22:06 ` Bill Kendall
2010-11-05 16:35 ` [PATCH v2 8/9] xfsrestore: remove nix_t wkendall
2010-11-12 23:25 ` Alex Elder
2010-11-05 16:35 ` [PATCH v2 9/9] xfsrestore: check for compatible xfsrestore wkendall
2010-11-12 23:25 ` Alex Elder
2010-11-12 23:25 ` [PATCH v2 0/9] xfsrestore dirent limitations and scaling issues 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=1289853517.2199.226.camel@doink \
--to=aelder@sgi.com \
--cc=wkendall@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