Messages in this thread | | | Date | Tue, 19 Oct 2004 18:56:46 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.9-rc4-mm1-U6 |
| |
* Florian Schmidt <mista.tapas@gmx.net> wrote:
> I don't get any oopses or panics, but i can observer a rather > interesting behaviour. When i enable the latency traces via > > echo 1 > /proc/sys/kernel/trace_enabled > > my machine starts to make little pauses of ca 3-4 secs. X "hangs" for > this duration and so does aplay when playing a .wav file. "hangs" > means that the X display seems to be locked. Interestingly enough all > keystrokes i entered during the "hang" seem to arrive fine after the > hang has ended. aplay experiences an xrun.
do you get the same pauses if you do 'dmesg -n 1'? Also, are you using preempt_thresh or the maximum-searching variant? preempt_thresh can generate _tons_ of messages with a low threshold, freezing the system in essence for long periods of time.
but this trace is weird:
> preemption latency trace v1.0.7 on 2.6.9-rc4-mm1-RT-U6 > ------------------------------------------------------- > latency: 1841 us, entries: 4000 (12990) | [VP:1 KP:1 SP:1 HP:1 #CPUS:1] > ----------------- > | task: aplay/2160, uid:1000 nice:0 policy:0 rt_prio:0 > ----------------- > => started at: __schedule+0x3b/0x5d0 <c02a767b> > => ended at: finish_task_switch+0x43/0xb0 <c0114ae3> > =======> > 00000001 0.000ms (+0.000ms): __schedule (ksoftirqd) > 00000001 0.000ms (+0.000ms): sched_clock (__schedule) > 00000002 0.000ms (+0.000ms): deactivate_task (__schedule) > 00000002 0.000ms (+0.000ms): dequeue_task (deactivate_task) > 04000002 0.000ms (+0.000ms): __switch_to (__schedule) > 04000002 0.001ms (+0.000ms): finish_task_switch (__schedule) > 04000000 0.001ms (+0.000ms): schedule (down_write) > 04000000 0.001ms (+0.000ms): __schedule (down_write) > 04000001 0.001ms (+0.000ms): sched_clock (__schedule) > 04000000 0.001ms (+0.000ms): schedule (down_write) > 04000000 0.001ms (+0.000ms): __schedule (down_write) > 04000001 0.002ms (+0.000ms): sched_clock (__schedule) > 04000000 0.002ms (+0.000ms): schedule (down_write)
this doesnt seem like normal behavior. It seems two tasks are ping-pong-ing a semaphore but are unable to make any progress. The whole thing is non-preemptible because this semaphore was taken while in a PREEMPT_ACTIVE section.
(i'd say this is the BKL semaphore - it is quite special in that regard.)
Ingo - 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/
| |