On Wed, 29 Jun 2005, Ingo Molnar wrote:
> great! The SMP box running BurnP6 is another system, right? Could you
> sum up the remaining regressions you are seeing under -RT? (the
> latency.c warning is one, what others are remaining?)
Right. I'm doing the bulk of my RT testing on three machines:
Home: UP Athlon 2GHz VIA KT400 desktop, audio & MIDI dev
Work: UP Xeon 1.8GHz Intel 845 video encoding & mcast streaming
Work: SMT Xeon/HT 3.2GHz Intel 865 desktop, video streaming testing
Here's the max wakeup latencies I'm seeing on each machine with -50-35:
Athlon 15us
Xeon 22us
Xeon/HT 290us
In all fairness, the Xeon/HT machine is still running with the debug and
trace options enabled, while the other two have all debug except wakeup
latency timing disabled.
On UP, everything looks good. No JACK xruns, even while running burnK7.
Streaming with VLC from a Hauppauge card to UDP/multicast is almost
flawless (usually takes at least a day before any UDP packets are sent out
too late). I only saw one warning in my logs on the Athlon box for the
whole -50 series, and that was in -50-15. The non-HT Xeon box hasn't seen
any bug warnings since plist_init() on -48-33.
On SMT, everything works well under normal desktop load (X, wmaker, 10
dockapps, 10-20 xterms, and firefox). VLC runs very smoothly when I'm not
stress-testing. System responsiveness is much better than the
vanilla kernels. Wakeup latencies have decreased since the -48 series
(generally <100us, spiking to <300us now instead of generally <200us
spiking to <1000us).
When it comes to stress testing, I'm still finding conditions where CPU
hungry processes (like burnP6) can make the box completely unresponsive.
So far, I've narrowed it down to the following conditions: X is running
(xorg-6.8.2), along with two burnP6 instances, and X apps that are
actively updating the screen (like VLC or a collection of wmaker
dockapps). If one of these conditions is absent, there's no meltdown.
I've been toying with a script to fire up two instances of burnP6, grab
some traces with your trace-it code, and kill off those burnP6 processes.
The script generally takes the form:
#!/bin/bash
trace-it > trace1.out
sync
burn &
usleep 100000
trace-it > trace2.out
sync
burn &
usleep 100000
trace-it > trace2.out
sync
killall burn
I copied 'burnP6' to 'burn' so that the process name shows up in the
traces. Every time system response disappears, I never get any traces
after the second burnP6 fires up. Most of the time, I can still move the
mouse pointer for a few minutes (with serio lost synchro warnings on the
serial console) before it goes dead, too. Keyboard is almost always lost.
The results of two tests (one resulting in a meltdown) are located at:
http://sysex.net/testing/2.6.12-RT-V0.7.50-35
The 'test' directory has some traces with X and burnP6 (no VLC or
dockapps) running. These traces have chunks of dead time ranging from
roughly 500 to 900 us.
The 'crash' directory has a trace with X, burnP6, and VLC running, and a
bug warning. As soon as the second burnP6 instance started up, the system
showed no signs of being alive other than the mouse synchro warnings on
the serial console.
Overall, I would have to say that RT_PREEMPT is nearly ready for
primetime, especially for audio, MIDI, and video. SMT needs some help
when it comes to doing anything that requires X. I'm not sure about true
SMP, since I can't find a true SMP system to play with right now.
Great Work, Ingo!
Best Regards,
--ww
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
