Re: [linux-audio-user] Tracking down overruns

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] Tracking down overruns
From: Benji Flaming (lau_AT_solobanjo.com)
Date: Mon Sep 15 2003 - 11:34:54 EEST


Just wanted to post one final update before I go to bed (which I should have
done hours ago.) I spent quite a while playing with disk buffer settings,
looking through the kernel source, and digging up info online. Needless to
say, I learned a *lot* along the way. I made some tweaks, including
changing the values of 4 numeric constants in the kernel source, and
altering the values of /proc/sys/vm/dirty_*

The changes I made *did* seem to improve performance (at least on the
benchmarks), but I was still getting big spikes on the disk write graph,
caused (as Mark pointed out) by the journal being written to a different
part of the disk. It took me several hours to remember that my disused
Debian partition was formatted as ext2. Upon remembering this, I ran the
test on this partition, and achieved maximum latencies of 1.5-1.6 ms. for
all 5 tests. Here are the results of running latencytest-0.42-png on both
filesystems, with and without the disk buffer modifications:

reiserfs, without tweaks:
http://www.comevisit.com/NorthernSunrise/latency/regularreiserfs/3x256.html

reiserfs, with tweaks:
http://www.comevisit.com/NorthernSunrise/latency/tweakedreiserfs/3x256.html

ext2, without tweaks:
http://www.comevisit.com/NorthernSunrise/latency/regularext2/3x256.html

ext2, with tweaks:
http://www.comevisit.com/NorthernSunrise/latency/tweakedext2/3x256.html

The biggest bottleneck is certainly the journal, but the disk buffers appear
to be contributing a little bit as well. The changes that I made were
fairly extreme, not to mention uneducated. I suspect that these changes
would also have a strong detrimental effect on overall data throughput,
since I essentially crippled the entire caching system. I'd be interested
in seeing whether continued experimentation could lead to the same 1.6
millisecond results with milder settings. Just for the record, the changes
I made were:

- Changed MAX_WRITEBACK_PAGES in mm/page-writeback.c from 1024 to 8
- Changed ratelimit_pages in mm/page-writeback.c from 32 to 2
- Changed MIN_PDFLUSH_THREADS in mm/pdflush.c from 2 to 16
- Changed MAX_PDFLUSH_THREADS in mm/pdflush.c from 8 to 32
- Changed /proc/sys/vm/dirty_background_ratio from 10 to 1
- Changed /proc/sys/vm/dirty_expire_centisecs from 3000 to 1
- Changed /proc/sys/vm/dirty_ratio from 40 to 1
- Changed /proc/sys/vm/dirty_writeback_centisecs from 500 to 1

The basic idea was to force frequent buffer flushes, make each flush
smaller, and spread the flushes throughout different threads to stagger the
timing.

I'm off to get some sleep now. Thanks to everyone for the help!

|)
|)enji

Benjamin Flaming
--------------------
"The trouble with computers, of course, is that they're very sophisticated
idiots."


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Sep 15 2003 - 11:52:50 EEST