Messages in this thread | | | Date | Tue, 16 Nov 2004 23:31:35 +0100 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm1-V0.7.27-3 |
| |
* 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 - 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/
| |