Messages in this thread | | | Date | Fri, 13 Aug 2004 12:54:06 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Latency Tracer, voluntary-preempt-2.6.8-rc4-O6 |
| |
* 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 - 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/
| |