Thread (14 messages) 14 messages, 3 authors, 2007-04-22

Re: major performance drop on raid5 due to context switches caused by small max_hw_sectors [partially resolved]

From: Justin Piszcz <hidden>
Date: 2007-04-22 14:48:11


On Sun, 22 Apr 2007, Pallai Roland wrote:
On Sunday 22 April 2007 13:42:43 Justin Piszcz wrote:
quoted
http://www.rhic.bnl.gov/hepix/talks/041019pm/schoen.pdf
Check page 13 of 20.
Thanks, interesting presentation. I'm working in the same area now, big media
files and many clients. I spent some days to build a low-cost, high
performance server. With my experience, I think, some results of this
presentation can't be applied to recent kernels.

It's off-topic in this thread, sorry, but I like to swagger what can be done
with Linux! :)

ASUS P5B-E Plus, P4 641, 1024Mb RAM, 6 disks on 965P's south bridge, 1 disk on
Jmicron (both driven by AHCI driver), 1 disk on Silicon Image 3132, 8 disks
on HPT2320 (hpt's driver). 16x Seagate 500Gb 16Mb cache.
kernel 2.6.20.3
anticipatory scheduler
chunk size 64Kb
XFS file system
file size is 400Mb, I read 200 of them in each test

The yellow points are marking thrashing thresholds, I computed it based on
process number and RAM size. It's not an exact threshold.

- now see the attached picture :)

Awesome performance, near disk-platter speed with big RA! It's even better
with ~+15% if I use the -mm tree with the new adaptive readahead! Bigger
files, bigger chunk also helps, but in my case, it's constant
(unfortunately).

The rule of readahead size is simple: the much is better, till no thrashing.


--
d
Have you also optimized your stripe cache for writes?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help