Re: [patch] Latency Tracer, voluntary-preempt-2.6.8-rc4-O6

Ingo Molnar
2004-08-13T10:52:50Z

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

> Hmm, should a new report only be generated when the newly measured
> latency is really > than all other ones? I get the feeling that >=
> seems to be enough. Here a dmesg extract:
>
> (swapper/1): new 6 us maximum-latency critical section.
> (swapper/1): new 8 us maximum-latency critical section.
> (swapper/1): new 9 us maximum-latency critical section.

> Here are two reports with the same maximum-latency (31 us):
>
> (swapper/1): new 31 us maximum-latency critical section.
> (swapper/1): new 31 us maximum-latency critical section.

the latency tracer tracks latencies in cycle units - but they are
displayed at microsecond accuracy - hence these 'equal' latencies.

to jump-start all those smaller latencies you can do this:

echo 100 > /proc/sys/kernel/preempt_max_latency
echo 0 > /proc/sys/kernel/preempt_thresh

this way the maximum-searching only starts at 100 usecs.

> Btw: i do have some regular ca. 300 us latencies.. Here are some traces
> (these happen with an average frequency of ca. 0.3hz):

> (ksoftirqd/0/2): 307 us critical section violates 250 us threshold.
> => started at: <___do_softirq+0x20/0x90>
> => ended at: <cond_resched_softirq+0x59/0x70>

this is too opaque - could you try -O7, enable tracing and save a
/proc/latency_trace instance of such a latency? It looks like some sort
of softirq latency - perhaps one particular driver's timer fn causes it
- we'll be able to tell more from the trace.

Ingo