Messages in this thread Patch in this message | | | Date | Tue, 16 Nov 2004 23:42:57 +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:
> It seems this excerpt from below trace is characteristic for all the long > traces: > > 5 80000002 0.001ms (+1.114ms): __do_softirq (do_softirq) > 5 00000000 1.115ms (+0.000ms): preempt_schedule (_mmx_memcpy)
i've seen this before, it's still unsolved. This trace shows it nicely:
> 5 80010002 0.000ms (+0.000ms): wake_up_process (redirect_hardirq) > 5 80010001 0.000ms (+0.000ms): preempt_schedule (__do_IRQ) > 5 80010001 0.000ms (+0.000ms): irq_exit (do_IRQ) > 5 80000002 0.000ms (+0.000ms): do_softirq (irq_exit) > 5 80000002 0.001ms (+1.114ms): __do_softirq (do_softirq) > 5 00000000 1.115ms (+0.000ms): preempt_schedule (_mmx_memcpy) > 5 90000000 1.115ms (+0.000ms): __schedule (preempt_schedule) > 5 90000000 1.115ms (+0.000ms): profile_hit (__schedule)
this is either a false positive, or we missed a preemption. To see which one, could you apply the attached patch and try to reproduce this long trace? The new trace will tell us whether need_resched is set during that ~1 msec window.
Ingo
--- linux/kernel/latency.c.orig +++ linux/kernel/latency.c @@ -184,6 +184,7 @@ ____trace(struct cpu_trace *tr, unsigned * Encode irqs-off into the preempt count: */ + (irqs_disabled() ? 0x80000000 : 0) + + (need_resched() ? 0x08000000 : 0) #endif ; } - 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/
| |