public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Elder <aelder@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs_repair: multithread phase 2
Date: Wed, 05 Jan 2011 17:42:14 -0600	[thread overview]
Message-ID: <1294270934.2312.105.camel@doink> (raw)
In-Reply-To: <1294121588-17233-1-git-send-email-david@fromorbit.com>

On Tue, 2011-01-04 at 17:13 +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
> 
> Running some recent repair tests on broken filesystem meant running
> phase 1 and 2 repeatedly to reproduce an issue at the start of phase
> 3. Phase 2 was taking approximately 10 minutes to run as it
> processes each AG serially.
> 
> Phase 2 can be trivially parallelised - it is simply scanning the
> per AG trees to calculate free block counts and free and used inodes
> counts. This can be done safely in parallel by giving each AG it's
> own structure to aggregate counts into, then once the AG scan is
> complete adding them all together.
> 
> This patch uses 32-way threading which results in no noticable
> slowdown on single SATA drives with NCQ, but results in ~10x
> reduction in runtime on a 12 disk RAID-0 array.

This is great.  And evidently not very hard at all.  It should
have been done a long time ago...

I had a few of the same comments Christoph had (though
I didn't know about the the workqueues).  I'll reiterate
one, that SCAN_THREADS should be a command line option.
32 is a fine default, but there's no sense in restricting
it to that.

A few other things, below, but this looks good to me.

Reviewed-by: Alex Elder <aelder@sgi.com>

> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
>  repair/phase2.c |   16 +---
>  repair/scan.c   |  303 +++++++++++++++++++++++++++++++-----------------------
>  repair/scan.h   |   37 -------
>  3 files changed, 176 insertions(+), 180 deletions(-)

. . .
 
> diff --git a/repair/scan.c b/repair/scan.c
> index 85017ff..dd62776 100644
> --- a/repair/scan.c
> +++ b/repair/scan.c

. . .
 
> @@ -469,6 +477,34 @@ _("out-of-order bmap key (file offset) in inode %llu, %s fork, fsbno %llu\n"),
>  }
>  

Can this (and scanfunc_cnt() and scanfunc_ino()) be given
static scope now?

>  void
> +scanfunc_bno(
> +	struct xfs_btree_block	*block,
> +	int			level,
> +	xfs_agblock_t		bno,
> +	xfs_agnumber_t		agno,
> +	int			suspect,
> +	int			isroot,
> +	struct aghdr_cnts	*agcnts)
> +{
> +	return scanfunc_allocbt(block, level, bno, agno,
> +				suspect, isroot, XFS_ABTB_MAGIC, agcnts);
> +}
> +

. . .

> @@ -1155,42 +1169,15 @@ validate_agi(
>  }
. . .
> -void
> -scan_ag(
> -	xfs_agnumber_t	agno)
> +void *
> +scan_ag(void *args)

Maybe arg (singular)

>  {
> +	struct aghdr_cnts *agcnts = args;
> +	xfs_agnumber_t	agno = agcnts->agno;
>  	xfs_agf_t	*agf;
>  	xfs_buf_t	*agfbuf;
>  	int		agf_dirty = 0;

. . .

> @@ -1331,4 +1308,72 @@ scan_ag(
>  		libxfs_putbuf(sbbuf);
>  	free(sb);
>  	PROG_RPT_INC(prog_rpt_done[agno], 1);
> +
> +#ifdef XR_INODE_TRACE
> +	print_inode_list(i);

I know this is only under XR_INODE_TRACE, but
now that you're multi-threading these, the
output can get interleaved and therefore
somewhat useless.  Maybe you could adjust
print_inode_list() so it includes the AG
number with each line output rather than
just prior to printing all of them.

> +#endif
> +	return NULL;
> +}
> +
> +#define SCAN_THREADS 32

Make this configurable at runtime.

> +
> +void
> +scan_ags(
> +	struct xfs_mount	*mp)
> +{
> +	struct aghdr_cnts agcnts[mp->m_sb.sb_agcount];

There is some mention about the per-thread stack size
getting set at the time the program starts in the pthread
documentation.  I don't expect this will be a problem in
practice, but maybe this should be allocated dynamically.

> +	pthread_t	thr[SCAN_THREADS];
> +	__uint64_t	fdblocks = 0;
> +	__uint64_t	icount = 0;
> +	__uint64_t	ifreecount = 0;
> +	int		i, j, err;
> +
> +	/*
> +	 * scan a few AGs in parallel. The scan is IO latency bound,
> +	 * so running a few at a time will speed it up significantly.
> +	 */
> +	for (i = 0; i < mp->m_sb.sb_agcount; i += SCAN_THREADS) {
> +		for (j = 0; j < SCAN_THREADS; j++) {
			xfs_agnumber_t agno = i + j;

> +			if (i + j >= mp->m_sb.sb_agcount)

			if (agno >= mp->m_sb.sg_agcount)
				(and so on, throughout this section)

> +				break;
> +			memset(&agcnts[i + j], 0, sizeof(agcnts[i]));
							agcnts[i + j]

> +			agcnts[i + j].agno = i + j;
> +			err = pthread_create(&thr[j], NULL, scan_ag,
> +							&agcnts[i + j]);
> +			if (err)


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

  parent reply	other threads:[~2011-01-05 23:40 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-04  6:13 [PATCH] xfs_repair: multithread phase 2 Dave Chinner
2011-01-04 10:02 ` Christoph Hellwig
2011-01-04 12:00   ` Dave Chinner
2011-01-05 23:42 ` Alex Elder [this message]
  -- strict thread matches above, loose matches on Subject: below --
2011-01-10  0:44 Dave Chinner
2011-01-10  7:57 ` Michael Monnerie
2011-01-10  8:41   ` Dave Chinner
2011-01-10 13:25     ` Michael Monnerie
2011-01-10 19:18       ` Christoph Hellwig
2011-01-10 19:17     ` Christoph Hellwig
2011-01-10 21:53       ` Matthias Schniedermeyer
2011-01-10 18:55 ` Christoph Hellwig
2011-02-01 23:39 ` 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=1294270934.2312.105.camel@doink \
    --to=aelder@sgi.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox