That's my thought. The checksumming speed doesn't remain static regardless of what's being checksummed. If I want to calculate double parity on a stripe that spans 30 disks I'd expect that to be more CPU intensive than calculating double parity on a 3 disk stripe. On Tue, Jun 5, 2012 at 7:40 PM, Brad Campbell <lists2009@xxxxxxxxxxxxxxx> wrote: > On 06/06/12 02:44, Ole Tange wrote: >> >> On Tue, Jun 5, 2012 at 1:29 PM, Igor M Podlesny<for.poige+lsr@xxxxxxxxx> >> wrote: >>> >>> On 5 June 2012 15:47, Ole Tange<ole@xxxxxxxx> wrote: >>>> >>>> On Tue, Jun 5, 2012 at 5:39 AM, Igor M Podlesny<for.poige+lsr@xxxxxxxxx> >>>> wrote: >>>>> >>>>> On 5 June 2012 07:14, Ole Tange<ole@xxxxxxxx> wrote: >>>>> […] >>>>>> >>>>>> I tested this by creating 24 devices in RAM, used different chunk >>>>>> sizes, and then copied the linux kernel source. Test script can be >>>>>> found on >>>>>> http://oletange.blogspot.dk/2012/05/software-raid-performance-on-24-disks.html >> >> : >>> >>> Wanna try CONFIG_MULTICORE_RAID456? :-) >> >> >> If the kernel can checksum 6196 MB/s why would I need >> CONFIG_MULTICORE_RAID456? Please elaborate on why you think that is >> needed. > > > I'd have thought there was a significant difference between the test > generating that figure (being a large, single block being checksummed) and > shunting around blocks from 20 odd block devices, arranging them and > checksumming them. > > I'm not debating the validity of your tests at all, however I do question > your assertion than a single raid6 thread should even get close to that > theoretical figure when actually doing real work. > > Why not do as the man suggested and enable CONFIG_MULTICORE_RAID456 and see > what happens? > > Regards, > Brad > > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
