On Mon, Nov 12, 2001 at 06:34:17PM -0500, Fred Gleason wrote: > I've been dealing with an interesting situation here regarding a system > that is running three software RAID arrays. The layout consists of two > RAID1 arrays sharing two IDE drives and a RAID5 array running on five SCSI > drives (four active and one on hot standby). Latency tests on the system > show a very regular series of latency spikes occurring at around 5.2 > second intervals during the disk write phase. > > I've posted the test results at http://www.wava.com/ll_results. Has > anyone out there done any work regarding RAID as it bears upon low > latency?
Interesting! I'm honestly amazed (and impressed) that running RAID5 doesn't send your latency results through the roof. Imagine if software RAID5 were fast enough for professional audio work; that's pretty cool. Anyway, try using Robert Love's pre-empt kernel patches[1]; you might get a better result with them than you do with the low-latency patches. The pre-empt patches will pre-empt the kernel _everywhere_; the low-latency patches put in conditional reschedules in certain areas of the kernel only. My bets are that the RAID layer hasn't been low-latencised (that's definitely not a word) yet, which is why you're seeing zero change in performance. Even if the pre-empt patches don't help you, there's a marvellous pre-empt stats patch which will let you read a file from /proc containing information on which function(s) in the kernel are causing the latency spikes. Send this to the kernel list and I'm sure somebody will be procrastinating enough to fix the RAID layer :). [1] http://www.tech9.net/rml/linux/ -- #ozone/algorithm <[EMAIL PROTECTED]> - trust.in.love.to.save
