lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20090703163011.GA7476@ben-laptop>
Date:	Fri, 3 Jul 2009 11:30:11 -0500
From:	Ben Gamari <bgamari.foss@...il.com>
To:	linux-kernel@...r.kernel.org, intel-gfx@...ts.freedesktop.org
Subject: Re: Infrastructure for tracking driver performance events

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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ