Messages in this thread |  | | Date | Wed, 11 Jan 2012 17:26:44 +0100 | | From | Frederic Weisbecker <> | | Subject | Re: [PATCH 8/9] stacktrace: implement save_stack_trace_quick() |
| |
On Tue, Jan 10, 2012 at 10:28:25AM -0800, Tejun Heo wrote: > Implement save_stack_trace_quick() which only considers the usual > contexts (ie. thread and irq) and doesn't handle links between > different contexts - if %current is in irq context, only backtrace in > the irq stack is considered.
The thing I don't like is the duplication that involves not only on stack unwinding but also on the safety checks.
What about making struct stacktrace_ops::stack() return a value that either stops or continue the trace? In your case EOE/EOI would be the triggering condition.
Filtering stack contexts might in fact be a desirable generic feature overall.
At least in perf we could be interested in filtering kernel/user contexts. And in your case in stopping after the first context. I also don't know if we will be interested in filtering irq/exception/process stacks in the future but I prefer to ensure we have a flexible enough interface to allow that.
So it may be a good idea to reuse the exisiting code for your needs like a stack() return value as above. And if the post processing will be done from userspace (which I really hope) then extend the ftrace/perf interface to allow your quick filtering, something that can be later extended to allow more finegrained stacktrace filtering.
> This is subset of dump_trace() done in much simpler way. It's > intended to be used in hot paths where the overhead of dump_trace() > can be too heavy.
Is it? Have you found a measurable impact (outside the fact you record only one stack).
Thanks.
|  |