Re: Infrastructure for tracking driver performance events

[Ben Gamari <bgamari.foss@gmail.com>]

On Thu, Jun 25, 2009 at 08:55:51AM -0400, Steven Rostedt wrote:
> 
> 
> On Wed, 24 Jun 2009, Ben Gamari wrote:
> You can filter on functions to trace. Or add a list of functions
> in set_graph_function to just graph a specific list.

Perfect.

> 
> > 2) It is difficult to extract the kernel mode callgraph with no natural
> >    way to capture the usermode callgraph
> 
> Do you just need a backtrace of some point, or a full user mode graph?

Just a backtrace to the syscall invocation. This should allow us to
identify which path mesa or the ddx took to hit the slow path.

> 
> > 3) A large amount of usermode support is necessary (which will likely be
> >    the case for any option; listed here for completeness)
> > 
> > Another option seems to be systemtap. It has already been documented[3]
> > that this option could provide both user-mode and kernel-mode
> > backtraces. The driver could provide a kernel marker at every potential
> > wait point (or a single marker in a function called at each wait point,
> > for that matter) which would be picked up by systemtap and processed in
> > usermode, calling ptrace to acquire a usermode backtrace. This approach
> > seems slightly cleaner as it doesn't require the tracing on the entire
> > machine to catch what should be reasonably rare events (hopefully).
> 
> Enabling the userstacktrace will give userspace stack traces at event
> trace points. The thing is that the userspace utility must be built with 
> frame pointers.

Yep, I apparently hadn't read through the documentation all that well.
It looks like the stacktrace and userstacktrace will serve quite nicely.
Are there preexisting tools for resolving addresses in the produced
stacktrace into symbols? Is there an example of this being done
somewhere? Thanks,

- Ben