Re: [PATCH 3/3] tracing/function-return-tracer: add the overrunfield

[Steven Rostedt]

On Mon, 17 Nov 2008, Ingo Molnar wrote:

> 
> * Frederic Weisbecker <fweisbec@xxxxxxxxx> 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.

I was just looking at the stack tracer, and it pretty much gives us the 
answer ;-)  I'm hitting on max traces around 55, but some of those are asm 
calls. We could do 50 or 60?  We probably want to make sure that the two 
do not come close to hitting. That is, the bottom of the stack to 
overwrite the saved return addresses.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/