xfs
[Top] [All Lists]

Re: Linux RAID & XFS Question - Multiple levels of concurrency = faster

To: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>
Subject: Re: Linux RAID & XFS Question - Multiple levels of concurrency = faster I/O on md/RAID 5?
From: John Robinson <john.robinson@xxxxxxxxxxxxxxxx>
Date: Sat, 01 Nov 2008 12:14:44 +0000
Cc: linux-raid@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx
In-reply-to: <alpine.DEB.1.10.0811010758240.1053@xxxxxxxxxxxxxxxx>
Organization: None; Disorganization: Total
References: <alpine.DEB.1.10.0811010424270.16517@xxxxxxxxxxxxxxxx> <490C359F.7080504@xxxxxxxxxxxxxxxx> <alpine.DEB.1.10.0811010758240.1053@xxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666
On 01/11/2008 12:00, Justin Piszcz wrote:
On Sat, 1 Nov 2008, John Robinson wrote:
On 01/11/2008 08:29, Justin Piszcz wrote:
[...]
Why is running 3 jobs con-currently that take care of two parts each more than
twice as fast than running one job for six parts?

Because you have multiple CPUs?

So 1/4 of a quad core q6600 cannot achieve higher rates of I/O due to the
parity operations being that costly?

Is the only way to increase the single-threaded speed to increase the maximum CPU core speed/get a faster CPU, and/or theoretically a multi-threaded md-raid
could maximize throughput?

Actually I was thinking that your test job - I think you said it used tar - is single-threaded and CPU-bound on one core, and doesn't saturate the MD subsystem. Your jobs are 75% user time to 25% system time, and the user time is not parellelisable until you do it yourself by splitting the work up.

Cheers,

John.

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