Subject: [linux-audio-dev] lowish-latency patch and toolchain
From: Andrew Morton (andrewm_AT_uow.edu.au)
Date: Sat Jul 08 2000 - 08:36:45 EEST
I now have six fs-related rescheduling points and as long as one avoids
doing silly things, the scheduling latency is reliably 4 milliseconds on
a 500MHz machine. Very occasionally reaches 7 millisecs. It has been
tested during kernel builds, netperf, lmbench, mmap001, mmap002,
x11perf, general ext2 and NFS hammering, general usage.
So I'll now ask interested parties to apply the attached patch to
2.4.0-test3-pre4 or later (the ones with Roger's VM patches) and try to
break it.
Prove to me that there are any remaining scheduling problems which don't
have simple DDT ("Don't do that") workarounds.
Here's the current DDT list:
- Don't futz with fbcon. This was covered today on the
kernel mailing list.
- Don't delete huge files (100 megs). There's a hungry
loop in zap_page_range which has no clear-and-easy fix.
There _was_ a fix in Ingo's patch, but additional 2.4
threading has made that unviable.
- Don't munmap() huge files. zap_page_range() will zap ya!
- Don't run out of memory. If you push kswapd hard it
will steal 50 milliseconds from you.
- Don't run `hdparm'. Tens of millisecs while setting
IDE disk parameters.
- Don't use blkdev_close(). This function is used when
raw block devices are closed and it soaks tens of
milliseconds. This will be used by LILO and fdisk, etc.
- Don't run mmap002!
- Don't load/unload kernel modules
Now, dear testers: if you _do_ find some scheduling bumps I've put up
some diagnostic tools which can be used to quantify them and to identify
their sources. They're at
http://www.uow.edu.au/~andrewm/linux/schedlat.html
These include:
timepegs
A general purpose tool for measuring point-to-point time
intervals in the kernel.
tpt
Tool for generating reports from /proc/timepeg
schedlat (aka syscall-timer.patch)
Tool which uses timepegs to measure the duration of kernel
scheduling blackouts.
amlat
A usermode program which puts "scheduling pressure" onto the
kernel, and allows rtc-debug to measure scheduling latencies.
(There's some of Benno's stuff in here)
rtc-debug
A patch against drivers/char/rtc.c which allows you to:
- Generate scheduling latency histograms
- Identify and generate a stack trace on "piggy processes".
You can then walk this backtrace to work out where in the
kernel the pigginess is happening.
- Identify a possible kernel priority-perversion bug. Still
looking into this.
rtc-debug currently goes a bit silly when used with CONFIG_SMP.
It doesn't crash, but it reports bogus priority perversion events.
It needs a #ifndef CONFIG_SMP...
If you think you've found something which causes a scheduling
dropout please take the following steps:
- Apply the timepeg patch
- Apply the schedlat patch (syscall-timer.patch)
- run `tpt -s'
- Run amlat
- Do whatever it is that causes the problem
- Kill amlat
- run `tpt -s | sort -nr +5 | tee tpt.log | more'
- Tell me.
Thanks.
This archive was generated by hypermail 2b28 : Sat Jul 08 2000 - 08:52:48 EEST