lkml.org 
[lkml]   [2008]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 3/3] tracing/function-return-tracer: add the overrun field

* Steven Rostedt <rostedt@goodmis.org> wrote:

>
> On Tue, 18 Nov 2008, Ingo Molnar wrote:
>
> >
> > * Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > >
> > > On Tue, 18 Nov 2008, Ingo Molnar wrote:
> > > > >
> > > > > 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?
> > >
> > > Don't run that on a box you care about ;-) But hopefully the stacks
> > > will not collide. This should also depend on IRQSTACKS.
> >
> > that reminds me: ti->ret_stack[] should be moved to task->ret_stack[].
> > That way we decouple its size from any kernel stack size limits.
> > (thread-info resides at one end of the kernel stack, on x86)
>
> Yeah, I recommended that to Frederic to save space. But that can be
> dangerous. Using task instead would be safer with the downside of
> making the task struct even bigger.

We almost never put new stuff into thread_info - we have the lockdep
lock stack in the task structure too, for similar reasons.

Ingo


\
 
 \ /
  Last update: 2008-11-18 16:17    [W:0.061 / U:0.452 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site