Messages in this thread | | | Date | Tue, 18 Nov 2008 09:47:55 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 3/3] tracing/function-return-tracer: add the overrun field |
| |
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> 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....
dunno, trampolines make me feel uneasy.
Could you set it to some really large value (200) and add a "max depth seen" variable perhaps, and see the maximum depth?
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/
| |