Messages in this thread | | | Date | Mon, 17 Nov 2008 19:38:29 +0100 | From | Frederic Weisbecker <> | Subject | Re: [PATCH 3/3] tracing/function-return-tracer: add the overrun field |
| |
Ingo Molnar a écrit : > * Frederic Weisbecker <fweisbec@gmail.com> wrote: > >> Impact: help to find the better depth of trace >> >> We decided to arbitrary define the depth of function return trace as >> "20". Perhaps this is not enough. To help finding an optimal depth, >> we measure now the overrun: the number of functions that have been >> missed for the current thread. By default this is not displayed, we >> have to do set a particular flag on the return tracer: echo overrun >>> /debug/tracing/trace_options And the overrun will be printed on >> the right. >> >> As the trace shows below, the current 20 depth is not enough. >> >> update_wall_time+0x37f/0x8c0 -> update_xtime_cache (345 ns) (Overruns: 2838) >> update_wall_time+0x384/0x8c0 -> clocksource_get_next (1141 ns) (Overruns: 2838) >> do_timer+0x23/0x100 -> update_wall_time (3882 ns) (Overruns: 2838) > > hm, interesting. Have you tried to figure out what a practical depth > limit would be? > > With lockdep we made the experience that function call stacks can be > very deep - if we count IRQ contexts too it can be up to 100 in the > extreme cases. (but at that stage kernel stack limits start hitting > us) > > I'd say 50 would be needed. > > Ingo
Ok I will try with 50. If there are still a lot and often missing traces with this depth, perhaps should we consider a hybrid solution between ret stack and trampolines? We could use the normal ret stack on struct info for most common cases and the trampoline when we are exceeding the depth....
-- 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/
| |