xfs
[Top] [All Lists]

Re: [PATCH] xfs_repair: multithread phase 2

To: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH] xfs_repair: multithread phase 2
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 10 Jan 2011 19:41:22 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <201101100857.53421@xxxxxx>
References: <1294620248-17098-1-git-send-email-david@xxxxxxxxxxxxx> <201101100857.53421@xxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Mon, Jan 10, 2011 at 08:57:52AM +0100, Michael Monnerie wrote:
> On Montag, 10. Januar 2011 Dave Chinner 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.
> 
> Is the fixed 32-way number reasonable, or shouldn't that be "number of 
> available cpu cores"-way? Why threading when you have a single core cpu?

Sure, 32-way is reasonable on a single disk and CPU. Pretty much
every sata disk supports NCQ these days, and default to a depth of
32, which means we can have 32 concurrent reads in progress at once.
Phase 2 is all synchronous IO, so the only way to hide the IO
latency is to queue work to multiple threads and switch between the
threadsto work on another queue when the current one blocks waiting
for IO.

Basically the threading being used to drive IO level concurrency,
not to drive CPU level concurrency - the total CPU usage of phase 2
is less than what even a slow CPU can provide, so to keep it busy we
need lots of concurrent IO streams in progress at once...

And if you want to change it, there's a command line option for it.

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

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