lkml.org 
[lkml]   [2008]   [Nov]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [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



    \
     
     \ /
      Last update: 2008-11-27 15:31    [W:0.071 / U:1.776 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site