Messages in this thread | | | Date | Thu, 27 Nov 2008 16:27:49 +0200 | From | Török Edwin <> | Subject | Re: [PATCH 2/2] tracing: identify which executable object the userspace address belongs to |
| |
On 2008-11-27 16:10, Ingo Molnar wrote: > Your patches are nice. Right now they are in tracing/core and > linux-next already.
Thanks. I can move on to the lock latency tracing ;)
I'll send out a draft of tracepoints that I would need to trace lock latency. I'll try to put them in same place as lockstat (but not necesarely depending on lockstat being enabled).
Once we reach a lock-tracepoints patch that all agree upon, I can (try to) write a ftrace-lock-latency that will have a histogram view (as you've suggested similar to what the likely/unlikely tracer already does), but also show separate counts per unique kernel/user stacktrace.
Or I could add the tracepoints inside lockstat (now that it has contend with points feature), and use the information already gathered by lockstat, but augment it with finer grained counts per kernel/user stacktrace. (again there would be an ftrace plugin that would register with the tracepoints, and show the per stacktrace statistic in /sys/kernel/debug/tracing/trace).
Which approach should I try first?
Although my goal would be to be able to use this feature by simply turning on a flag at runtime (whether something in /proc or /sys/kernel/debug), rather than rebooting to a different kernel, it may be easier to implement this at first by using what lockstat already provides, and later improving it to work w/o lockstat.
What do you think?
Best regards, --Edwin
| |