lkml.org 
[lkml]   [2004]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
Date
>i have released the -V0.7.1 Real-Time Preemption patch, which can be
>downloaded from:
>
> http://redhat.com/~mingo/realtime-preempt/

V0.7.1 had build problems but after applying V0.7.7, I got a clean build
and was able to do some testing.

- single user and telnet 5 were uneventful

- preempt_wakeup_timing (PWT) is still generating false positives on SMP

- after disabling PWT, I ran for over an hour without any latency
traces > 200 usec.

- no crashes, lockups, or other fatal behavior in that same period

- X test was generally OK. A few bursts of high overhead (> 1 msec)
on the CPU task and worst case was > 2 msec.

- top test was a little cleaner, but its worst case was much worse
(over 17 msec).

- network tests were similar, with even longer worst cases (21 msec and
32 msec)

- disk I/O tests had some really odd results. The write test was much
cleaner than read / copy. All tests had > 25 msec worst cases. The read
test also had a pretty consistent variation on CPU overhead, about 500 usec
range (compared to 1160 usec nominal duration) in CPU loop timing.

A few other things I noticed:
- whenever the real time test was active, responses to ping from another
system would basically stop until the real time test was done. In one case
about 25 ping packets were returned after a huge delay. From that, it
appears they were received but the return was delayed.
- cat /proc/interrupts showed that LOC was increasing on both CPU's
during the tests.
- the scheduler seems to prefer run my cpu_burn (nice'd) task instead
of updating the X display, doing the latency timing checks, ping responses,
and anything else that does useful work.
- the disk write test was REALLY SLOW, perhaps hundreds of Kbytes per
second instead of what I normally see. I took much longer than the real
time audio test. I checked with top and noticed that "fam" was taking
near 100% of CPU time. I closed my konqueror window (just happened to be
looking at my test directory) and fam usage went away and the disk writes
sped up considerably. I don't recall seeing this symptom on -T3 or
previous tests, may try that later today to see if this is an old problem
or not.

This appears to be more stable than anything else since -T3 but the
odd spikes and scheduling symptoms are quite troubling.
--Mark

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:1.085 / U:0.032 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site