I also meet this problem in several of my machines. If I change back
to kernel 2.6.18, it is
OK, but in 2.6.32 kernel, the performance is really poor.

At last I found a solution, set CONFIG_MULTICORE_RAID456=n when
compiling raid456 module,
then everything goes normal. My machines do have multicore cpu, so it
is weird :<
Maybe there is something wrong with the CONFIG_MULTICORE_RAID456 enabled code?

On Tue, Mar 16, 2010 at 8:41 PM, Jeremy Sanders
[off-list ref] wrote:

Hi - It seems our MD raid rebuild speeds are very slow with the new Fedora
2.6.32.9-70 kernel. We're only getting ~13MB/s:

[root@xback2 ~]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 sdb1[0] sdj1[10](S) sdk1[9] sdl1[8] sdi1[7] sdh1[6]
sdg1[5] sdf1[4] sde1[3] sdd1[2] sdc1[1]
     8788959360 blocks level 5, 32k chunk, algorithm 2 [10/10] [UUUUUUUUUU]
     [=====>...............]  resync = 29.3% (286397320/976551040)
finish=897.2min speed=12819K/sec

The maximum rebuild speed is at the default 200000K/s. The drives are
connected to a 3ware 9650SE-16ML controller on PCI-Express.

There seem to be hundreds of async/X threads, where X goes up to 129 at
least. The md0_raid5 process is using at least 80% of the CPU on this dual
core Athlon 7750 system.

Has anything changed recently in the kernel. I don't remember md0_raid5
being so processor inefficient, slow at rebuilding or creating hundreds of
kernel threads.

Are these async/X threads documented anywhere?

Thanks

Jeremy



--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
tao.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html