Re: [PATCH 0/3] md fixes for 2.6.32-rc

[Asdo <asdo@shiftmail.org>]

Holger Kiehl wrote:
> On Tue, 6 Oct 2009, Dan Williams wrote:
>
>> ....
>> By downleveling the parallelism to raid_run_ops the pathological
>> stripe_head bouncing is eliminated.  This version still exhibits an
>> average 11% throughput....
>>
>> So we don't need a revert, this fixes up the unpredictability of the
>> original implementation.  It surprised me that the overhead of passing
>> raid_run_ops to the async thread pool amounted to an 11% performance
>> regression.  In any event I think this is a better baseline for future
>> multicore experimentation than the current implementation.
>>
> Just to add some more information, I did try this patch with
> 2.6.32-rc3-git1 and with the testing I am doing I get appr. 125%
> performance regression. 
Hi Holger

 From the above sentence it seems you get worse performance now than 
with the original multicore implementation, while from the numbers below 
it seems you get better performances now.

Which is correct?

(BTW a performance regression higher than 100% is impossible :-) )

> The tests I am doing is have several (appr. 60
> process) sending via FTP or SFTP about 100000 small files (average size
> below 4096 bytes) to localhost in a loop for 30 minutes. Here the
> real numbers:
>
>  with multicore support enabled (with your patch)    3276.77 files per 
> second
>  with multicore support enabled (without your patch) 1014.47 files per 
> second
>  without multicore support                           7549.24 files per 
> second
>
> Holger

Also, could you tell us some details about your machine and the RAID?
Like the model of CPU (Nehalems and AMDs have much faster memory access 
than earlier intels) and if it's a single-cpu or a dual cpu mainboard...
Amount of RAM
also: stripe_cache_size current setting for your RAID
Raid level, number of disks, chunk size, filesystem...

Thank you!