From: Brad Campbell <lists2009@fnarfbargle.com>
To: Ole Tange <ole@tange.dk>
Cc: linux-raid@vger.kernel.org
Subject: Re: Software RAID checksum performance on 24 disks not even close to kernel reported
Date: Wed, 06 Jun 2012 20:58:07 +0800 [thread overview]
Message-ID: <4FCF53DF.3010001@fnarfbargle.com> (raw)
In-Reply-To: <CA+4vN7y+W2y2bDWu4JH9KBLD+pP6DcCdRVf7mxQ_6us5EZ5yhw@mail.gmail.com>
On 06/06/12 19:17, Ole Tange wrote:
> But if I try that setup on the test in RAM, md0_raid6 still takes up
> more CPU time than the checksumming would account for.
What part of "and shunting around blocks from 20 odd block devices,
arranging them and checksumming them." are you missing?
The number your kernel gives you at bootup is to take a block of data
and checksum it. In your real world results (in the same thread as the
one doing the checksum) you are juggling the IO from all the disks,
managing the buffers that result from that and calculating all the block
positions. In what conceivable way can you conclude that a single thread
can do all that and still give you the throughput the fabricated
benchmark does?
>> Why not do as the man suggested and enable CONFIG_MULTICORE_RAID456 and see
>> what happens?
>
> It is a lot of work to put into testing something that is at best a guess.
Can lead a horse to water.
Regards,
Brad
next prev parent reply other threads:[~2012-06-06 12:58 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-04 23:14 Software RAID checksum performance on 24 disks not even close to kernel reported Ole Tange
2012-06-05 1:26 ` Joe Landman
2012-06-05 3:36 ` Igor M Podlesny
2012-06-05 7:47 ` Ole Tange
2012-06-05 11:25 ` Peter Grandi
2012-06-05 20:57 ` Ole Tange
2012-06-06 17:37 ` Peter Grandi
2012-06-05 14:15 ` Stan Hoeppner
2012-06-05 20:45 ` Ole Tange
2012-06-05 3:39 ` Igor M Podlesny
2012-06-05 7:47 ` Ole Tange
2012-06-05 11:29 ` Igor M Podlesny
2012-06-05 13:09 ` Peter Grandi
2012-06-05 21:17 ` Ole Tange
2012-06-06 1:38 ` Stan Hoeppner
2012-06-05 18:44 ` Ole Tange
2012-06-06 1:40 ` Brad Campbell
2012-06-06 3:48 ` Marcus Sorensen
2012-06-06 11:21 ` Ole Tange
2012-06-06 11:17 ` Ole Tange
2012-06-06 12:58 ` Brad Campbell [this message]
2012-06-06 14:11 ` Ole Tange
2012-06-06 16:05 ` Igor M Podlesny
2012-06-06 19:51 ` Ole Tange
2012-06-06 22:21 ` Igor M Podlesny
2012-06-06 22:53 ` Peter Grandi
2012-06-07 3:41 ` Igor M Podlesny
2012-06-07 4:59 ` Stan Hoeppner
2012-06-07 5:22 ` Igor M Podlesny
2012-06-07 9:03 ` Stan Hoeppner
2012-06-07 9:22 ` Igor M Podlesny
2012-06-06 16:09 ` Dan Williams
2012-06-06 19:19 ` Ole Tange
2012-06-06 19:24 ` Dan Williams
2012-06-06 19:26 ` Ole Tange
2012-06-07 4:06 ` Stan Hoeppner
2012-06-07 14:40 ` Joe Landman
2012-06-08 1:23 ` Stan Hoeppner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FCF53DF.3010001@fnarfbargle.com \
--to=lists2009@fnarfbargle.com \
--cc=linux-raid@vger.kernel.org \
--cc=ole@tange.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.