Messages in this thread | | | Date | Fri, 17 Oct 2008 12:58:45 -0400 | From | "Frank Ch. Eigler" <> | Subject | Re: tracepoints for kernel/mutex.c |
| |
Hi -
On Fri, Oct 17, 2008 at 12:43:52PM -0400, Mathieu Desnoyers wrote: > [...] > > > _IFF_ you want to place tracepoints, get them in the same place as the > > > lock-dep/stat hooks, that way you get all the locks, not only mutexes. > > > > makes sense. So we could layer lock-dep/stat on top of tracepoints? That > > would potentially also make lock-dep/stat more dynamic.
> Guys, please, let's focus on the infrastructure to manage trace data > (timestamping, buffering, event ID, event type management) before > going any further in the instrumentation direction.
Any trace data management widget design that precludes connection to an event source as simple as tracepoints or markers is going to be a disappointment.
> Otherwise we will end up adding instrumentation in the Linux kernel > without any in-kernel user [...]
Connecting markers to /proc style text files has been demonstrated in less than a hundred lines of code.
Plus, Jason's note clearly referred to another in-kernel use of this instrumentation: the possibility of connecting lockdep via generic tracepoints in the lock-related code rather than special-purpose hooks. One benefit could be being able to compile in lockdep and/or lockstat by default (activating it via a boot option). The other would be of course the concurrent/alternative of the instrumentation for performance-related purposes.
- FChE
| |