Benno Senoner wrote:
>
> Hi,
>
> here the tests of Andrew's lowlatency patch on 2.4.0-test5-pre4:
>
> Unfortunately during disk writes it performs still quite bad , about 50msec
> during disk writes.
>
Benno,
You've just gone and measured the difference in efficiency between the
2.2.x and 2.4 VM systems :(
You see, hammering 360 megs out to disk wakes kswapd, and yes, kswapd
has been observed to spend sixty milliseconds without either sleeping or
blocking on I/O.
It's a known problem, hopefully a problem which will be fixed with
forthcoming 2.4 VM changes. I discussed this with Andrea at OLS last
week and didn't really understand what he said, but it sounded like he
had it under control :)
I did not make any attempt to poke scheduling holes in the VM, because
that isn't remotely the way to fix this problem.
Running the huge-write test on this very modest laptop gives a
worst-case scheduling latency of 6 milliseconds. Yup, it was in
kswapd. I have 256 megs or RAM. You have 64.
Ingo's 2.2 patch _must_ give better results than my 2.4 patch because
the 2.2 patch pokes probably hundreds of scheduling holes into the
kernel. Mine adds nine. But if you stay away from kswapd you'll
achieve sub 3 millisec scheduling.
Please take a look at my rtc-debug patch and the `amlat' application at
http://www.uow.edu.au/~andrewm/linux/schedlat.html - consider merging
some of it into your rtc patch. These thing do more than measure - they
tell you interesting things. I'll outline the algorithm here:
- amlat opens /dev/rtc, turns on a SIGIO stream
- rtc_open now clears its scheduling histogram.
For each rtc interrupt:
1: The ISR marks the time and sends amlat a SIGIO
2: amlat's signal handler reads from /dev/rtc
3: the rtc read() function notes the elapsed time
in the histogram.
When you kill amlat the rtc release() method dumps the histogram.
rtc-rebug also notes scheduling overruns and prints out the name of the
offending process and a stack backtrace. It's usually kswapd...
I really appreciate your work (and the code and ideas which I pinched
from you :)) But I have measurement, instrumentation and analysis tools
up the wazoo. All this stuff has been pretty carefully characterised.
What I'm seeking is confirmation that it works acceptably for real world
audio apps under real world conditions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:20 EST