Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3

[Ingo Molnar <mingo@elte.hu>]

* Florian Schmidt <mista.tapas@gmx.net> wrote:

> I have not yet tried to get this kernel to lock up yet, but i made
> another interesting observation:
> 
> irq 8 at prio 98 (only irq 1 with higher prio 99). running rtc_wakeup
> in the console (it runs SCHED_FIFO allright). Switching consoles
> (different text consoles - not swithcing to X, though this basically
> produces similar results) produces large jitters (around 1 ms) and
> occasional missed irq's and piggy messages. This is completely
> reproducable here. The rtc histogram doesn't show any large wakeup
> latencies.

interesting, i'll try to reproduce this.

btw., for best rtc_wakeup results you should chrt IRQ#0 to prio 99 too,
because it uses rtc_lock, otherwise it's an extra PI pass to undo the
lock inversion, which adds another 10 usecs or so to the worst-case
path.

and i'd suggest to chrt irq 1 back to below prio 90, maybe this explains
the console-switching latency? If you do a console-switch via the
keyboard then its priority 99 can get inherited by events/0 which then
does the quite expensive VGA console clearing/copying with priority 99,
possibly delaying rtc_wakeup quite significantly, easily for a
millisecond or so. So what you are seeing might be priority inheritance
handling at work!

> I sometimes do get large values in /proc/latency_trace, but they seem
> to be unrelated to the console switching.

could you post such a large latency trace? Are they like the bad traces
Mark is occasionally seeing, with some ridiculously large latency and a
ridiculously short execution trace?

	Ingo