From: Dan Christensen <jdc@uwo.ca>
To: linux-raid@vger.kernel.org
Subject: Re: RAID-5 streaming read performance
Date: Thu, 14 Jul 2005 22:38:47 -0400 [thread overview]
Message-ID: <87wtns7pzc.fsf@uwo.ca> (raw)
In-Reply-To: 87r7e23uo5.fsf@uwo.ca
Summary so far:
RAID-5, four SATA hard drives, 2.6.12.2 kernel. Testing streaming
read speed. With readahead optimized, I get:
each raw device: 58MB/s
raid device: 78MB/s
3 or 4 parallel reads
from the raw devices: 106MB/s
I'm trying to figure out why the last two numbers differ.
I was afraid that for some reason the kernel was requesting the parity
blocks instead of just the data blocks, but by using iostat it's
pretty clear that the right number of blocks are being requested from
the raw devices. If I write a dumb program that reads 3 out of every
4 64k chunks of a raw device, the kernel readahead kicks in and chunks
I skip over do contribute to the iostat numbers. But the raid layer
is correctly avoiding this readahead.
One other theory at this point is that my controller is trying to be
clever and doing some readahead itself. Even if this is the case, I'd
be surprised if this would cause a problem, since the data won't have
to go over the bus. But maybe the controller is doing this and is
causing itself to become overloaded? My controller is a Silicon Image
3114. Details at the end, for the record.
Second theory: for contiguous streams from the raw devices, the reads
are done in really big chunks. But for md layer reads, the biggest
possible chunk is 3 x 64k, if you want to skip parity blocks. Could
3 x 64k be small enough to cause overhead? Seems unlikely.
Those are my only guesses. Any others?
It seems strange that I can beat the md layer in userspace by 33%, by
just reading from three of the devices and using parity to reconstruct
the fourth!
Thanks again for all the help. I've learned a lot! And I haven't
even started working on write speed...
Dan
0000:01:0b.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)
Subsystem: Silicon Image, Inc. (formerly CMD Technology Inc): Unknown device 6114
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32, Cache Line Size: 0x08 (32 bytes)
Interrupt: pin A routed to IRQ 177
Region 0: I/O ports at 9400 [size=8]
Region 1: I/O ports at 9800 [size=4]
Region 2: I/O ports at 9c00 [size=8]
Region 3: I/O ports at a000 [size=4]
Region 4: I/O ports at a400 [size=16]
Region 5: Memory at e1001000 (32-bit, non-prefetchable) [size=1K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-
next prev parent reply other threads:[~2005-07-15 2:38 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-11 15:11 RAID-5 streaming read performance Dan Christensen
2005-07-13 2:08 ` Ming Zhang
2005-07-13 2:52 ` Dan Christensen
2005-07-13 3:15 ` berk walker
2005-07-13 12:24 ` Ming Zhang
2005-07-13 12:48 ` Dan Christensen
2005-07-13 12:52 ` Ming Zhang
2005-07-13 14:23 ` Dan Christensen
2005-07-13 14:29 ` Ming Zhang
2005-07-13 17:56 ` Dan Christensen
2005-07-13 22:38 ` Neil Brown
2005-07-14 0:09 ` Ming Zhang
2005-07-14 1:16 ` Neil Brown
2005-07-14 1:25 ` Ming Zhang
2005-07-13 18:02 ` David Greaves
2005-07-13 18:14 ` Ming Zhang
2005-07-13 21:18 ` David Greaves
2005-07-13 21:44 ` Ming Zhang
2005-07-13 21:50 ` David Greaves
2005-07-13 21:55 ` Ming Zhang
2005-07-13 22:52 ` Neil Brown
2005-07-14 3:58 ` Dan Christensen
2005-07-14 4:13 ` Mark Hahn
2005-07-14 21:16 ` Dan Christensen
2005-07-14 21:30 ` Ming Zhang
2005-07-14 23:29 ` Mark Hahn
2005-07-15 1:23 ` Ming Zhang
2005-07-15 2:11 ` Dan Christensen
2005-07-15 12:28 ` Ming Zhang
2005-07-14 12:30 ` Ming Zhang
2005-07-14 14:23 ` Ming Zhang
2005-07-14 17:54 ` Dan Christensen
2005-07-14 18:00 ` Ming Zhang
2005-07-14 18:03 ` Dan Christensen
2005-07-14 18:10 ` Ming Zhang
2005-07-14 19:16 ` Dan Christensen
2005-07-14 20:13 ` Ming Zhang
2005-07-15 2:38 ` Dan Christensen [this message]
2005-07-15 6:01 ` Holger Kiehl
2005-07-15 12:29 ` Ming Zhang
2005-07-13 22:42 ` Neil Brown
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=87wtns7pzc.fsf@uwo.ca \
--to=jdc@uwo.ca \
--cc=linux-raid@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).