Messages in this thread | | | Subject | Re: tracepoints for kernel/mutex.c | From | Peter Zijlstra <> | Date | Thu, 16 Oct 2008 23:34:38 +0200 |
| |
On Thu, 2008-10-16 at 17:04 -0400, Jason Baron wrote:
> Below are 3 tracepoints I've been playing with in kernel/mutex.c using > a SystemTap script. The idea is to detect and determine the cause of > lock contention. Currently I get the following output: > > <contended mutex nam> <process name and pid of the contention> <time of > contention> <pid that woke me up(caused the contention?)>
> I think this approach has a number of advantages. It has low > overhead in the off case, since its based on tracepoints. It is > minimally invasive in the code path (3 tracepoints). It also allows me > to explore data structures and parts of the kernel by simply modifying > the SystemTap script. I do not need to re-compile the kernel and reboot.
*sigh* this is why I hate markers and all related things...
_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.
This is the same reason I absolutely _hate_ Edwin's rwsem tracer.
Folks, lets please start by getting the tracing infrastructure in and those few high-level trace-points google proposed.
Until we get the basics in, I think I'm going to NAK any and all tracepoint/marker patches.
| |