public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lionel Bouton <Lionel.Bouton@free.fr>
To: "'Roy Sigurd Karlsbakk'" <roy@karlsbakk.net>
Cc: "'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: RAID question
Date: Wed, 07 Nov 2001 23:09:16 +0100	[thread overview]
Message-ID: <3BE9B10C.9060903@free.fr> (raw)
In-Reply-To: <06601B69B526914CB62E1C7B1663B5CA436014@w2kexgvie02>

Bene, Martin wrote:

>Hi Roy,
>
>>raid5: measuring checksumming speed
>>   8regs     :  1480.800 MB/sec
>>   32regs    :   711.200 MB/sec
>>   pIII_sse  :  1570.400 MB/sec
>>   pII_mmx   :  1787.200 MB/sec
>>   p5_mmx    :  1904.000 MB/sec
>>raid5: using function: pIII_sse (1570.400 MB/sec)
>>
>>Why is raid5 using function pIII_sse when p5_MMX is way faster?
>>
>
>The sse version is prefered over the others and gets used regardless of
>speed if it's available:
>
>/* We force the use of the SSE xor block because it can write around L2.
>   We may also be able to load into the L1 only depending on how the cpu
>   deals with a load to a line that is being prefetched.  */
>
As your cpu(s) work on the data before sending it back to the devices in 
the case of RAID5 and as in the general case memory writes invalidate an 
amount of L2 cache corresponding to the amount of data to write, you'll 
push out of L2 data of your running applications, hence slowing them down.

Imagine you have a block you want to write to/read from your 4k chunk 
size, 3 drive RAID 5 array.
For an atomic write, you'll read 8k from memory and write 12k back. It's 
20k of L2 cache involved. The 8k read may already be in cache (you write 
to disk what you worked on earlier) but the 12k are generated so they 
surely won't.
On x86 12-20k of L2 cache is a substansial amount of cache. And it's the 
lowest atomic read/write operation you can imagine, with 64kb chunck 
size and 5 drives it would be 64 x 5 = 320 to 64 x 9 = 576k -> whole L2 
invalidated on most modern x86 cpu.

What does cache give you ? Fast access to recently used memory and 
write-back capability.
Cache use in this case is *bad* because you won't reuse the cached data. 
Write-back won't give much (you stream whole chunks down the memory bus 
anyway).
You *may* slow down disk writes (if you have something near 2GB/s of 
disk bandwidth on your RAID...) but you'll *surely* slow down your 
applications a lot by taking away their data from your L2 cache(s).

So the raid code doesn't use the optimal disk throughput method, it uses 
the optimal system performance method...


  reply	other threads:[~2001-11-07 22:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-07 15:22 RAID question Bene, Martin
2001-11-07 22:09 ` Lionel Bouton [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-11-07 14:55 Roy Sigurd Karlsbakk
2001-05-03 21:38 OT: Here's the article text -- Microsoft Is Set to Be Top Foe of Free Code Miles Lane
2001-05-08  2:48 ` RAID question Peter Waltenberg
2001-05-08 15:07   ` Jakob Østergaard

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=3BE9B10C.9060903@free.fr \
    --to=lionel.bouton@free.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roy@karlsbakk.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox