lkml.org 
[lkml]   [2004]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [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/
\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.156 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site