linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bill Todd <billtodd@metrocast.net>
To: linux-raid@vger.kernel.org
Subject: md/RAID performance anomalies in 2.6 vs. 2.4
Date: Fri, 20 May 2005 23:02:19 -0400	[thread overview]
Message-ID: <428EA4BB.10703@metrocast.net> (raw)

Apologies if this issue has long since been addressed, but I Just 
stumbled upon last December's description of md's unusual performance 
behavior between the 2.4 and 2.6 environments and in looking at Neil's 
graphs the thought crossed my mind that it might be memory-related 
(especially given his statement that he incorporated some new cache in 
the latter plus the fact that he was juggling aggregate bandwidth across 
two busses).

Specifically, while RAID-5's streaming-read performance can approach 
RAID-0's for a given number of drives in the array, it can only do so if 
there's sufficient memory to post requests far enough ahead to keep both 
busses saturated - which requires more buffer space than RAID-0 does 
because of the staggered nature of the data layout in RAID-5 (and 
consequent tendency to alternate between saturating each bus and leaving 
it partially idle while the other is saturated, in the manner first 
encountered at the 5-drive level in RAID-0, unless requests have been 
posted far enough ahead to take advantage of those otherwise unused bus 
cycles).

Starting at the 6-drive level in his read throughput graph, it seems 
possible that the 2.4 configuration is providing more read-ahead buffer 
space for RAID-5 than the 2.6 configuration does (perhaps as a result of 
the new RAID cache which he has used in the latter) and thus allowing 
better smoothing across both busses (whereas for RAID-0 his new cache 
may be responsible for the smoother read performance above 6 drives than 
was the case in 2.4; RAID-6 might be expected to be less subject to 
either effect, if its two parity segments in each stripe are adjacent 
and thus guaranteed to be on separate busses).  I don't recall his 
stating whether he had drive-level opportunistic read-ahead enabled, nor 
am I sure how it might (or might not) affect things if it was.

But I suspect that he did not have drive-level write-back caching 
enabled, and that makes the sudden dip in RAID-0 2.6 write performance 
at the 5-drive level suggestive of bus imbalance as well, again perhaps 
occasioned by a scarcity of write buffer space, possibly again due to 
the new cache level (and might also help explain the RAID-5 
write-throughput differences between the two versions, though I really 
haven't thought either situation through very well).  The fact that the 
anomalous RAID-0 behavior disappeared on retest seems strange unless the 
drives' write-back caching might have been enabled for that second run 
(yes, seems unlikely).

- bill

                 reply	other threads:[~2005-05-21  3:02 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=428EA4BB.10703@metrocast.net \
    --to=billtodd@metrocast.net \
    --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).