From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH] xfs_repair: multithread phase 2
Date: Tue, 4 Jan 2011 23:00:49 +1100 [thread overview]
Message-ID: <20110104120048.GL15179@dastard> (raw)
In-Reply-To: <20110104100240.GB26885@infradead.org>
On Tue, Jan 04, 2011 at 05:02:40AM -0500, Christoph Hellwig wrote:
> > 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.
>
> Shouldn't we have at least an option to allow tuning this value,
> similar to the ag_stride? In fact I wonder why phase 3/4 should
> use different values for it than phase2.
Phase 3/4/5 use agressive prefetch to try to maximise throughput,
while phase 2 has no prefetch and uses synchronous reads.
Effectively the use of lots of parallelism simply keeps multiple IOs
in flight rather than reading them one at a time, hence reducing the
effective IO latency.
>
> > @@ -75,8 +80,10 @@ scan_sbtree(
> > xfs_agblock_t bno,
> > xfs_agnumber_t agno,
> > int suspect,
> > - int isroot),
> > - int isroot)
> > + int isroot,
> > + struct aghdr_cnts *agcnts),
> > + int isroot,
> > + struct aghdr_cnts *agcnts)
>
> Please make this a
>
> void *priv
>
> to keep scan_sbtree generic.
OK.
> > * Scan an AG for obvious corruption.
> > *
> > * Note: This code is not reentrant due to the use of global variables.
>
> That's not true any more I think.
Good point.
> > +#define SCAN_THREADS 32
> > +
> > +void
> > +scan_ags(
> > + struct xfs_mount *mp)
> > +{
> > + struct aghdr_cnts agcnts[mp->m_sb.sb_agcount];
> > + 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) {
>
> I think this should use the workqueues from repair/threads.c. Just
> create a workqueue with 32 threads, and then enqueue all the AGs.
Ok. I just used an API I'm familiar with and didn't have to think
about.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-01-04 11:58 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 [this message]
2011-01-05 23:42 ` Alex Elder
-- 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=20110104120048.GL15179@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--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.