13 Sep, 2009

9 commits

  • The entries used by ftrace internal code (plugins) currently have their
    formats manually exported to userspace. That is, the format files in
    debugfs/tracing/events/ftrace/*/format are currently created by hand.
    This is a maintenance nightmare, and can easily become out of sync
    with what is actually shown.

    This patch uses the methodology of the TRACE_EVENT macros to build
    the structures so that their formats can be automated and this
    will keep the structures in sync with what users can see.

    This patch only changes the way the structures are created. Further
    patches will build off of this to automate the format files.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • This patch increases the max string used by predicates to
    handle KSYM_SYMBOL_LEN.

    Also moves an include to look nicer.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • Documentation for event filters and formats.

    v2 changes: fix a few problems noticed by Randy Dunlap.

    Reviewed-by: Li Zefan
    Acked-by: Randy Dunlap
    Signed-off-by: Tom Zanussi
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Tom Zanussi
     
  • If the correspoding module is unloaded before ftrace_profile_disable()
    is called, event->profile_disable() won't be called, which can
    cause oops:

    # insmod trace-events-sample.ko
    # perf record -f -a -e sample:foo_bar sleep 3 &
    # sleep 1
    # rmmod trace_events_sample
    # insmod trace-events-sample.ko
    OOPS!

    Signed-off-by: Li Zefan
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Li Zefan
     
  • Only 24 bytes needs to be reserved on the stack for the function graph
    tracer on x86_64.

    Signed-off-by: Jiri Olsa
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Jiri Olsa
     
  • __start_mcount_loc[] is unused after init, yet occupies RAM forever
    as part of .rodata. 152kiB is typical on a 64-bit architecture. Instead,
    __start_mcount_loc should be in the interval [__init_begin, __init_end)
    so that the space is reclaimed after init.

    __start_mcount_loc[] is generated during the load portion
    of kernel build, and is used only by ftrace_init(). ftrace_init is declared
    '__init' and is in .init.text, which is freed after init.
    __start_mcount_loc is placed into .rodata by a call to MCOUNT_REC inside
    the RO_DATA macro of include/asm-generic/vmlinux.lds.h. The array *is*
    read-only, but more importantly it is not used after init. So the call to
    MCOUNT_REC should be moved from RO_DATA to INIT_DATA.

    This patch has been tested on x86_64 with CONFIG_DEBUG_PAGEALLOC=y
    which verifies that the address range never is accessed after init.

    Signed-off-by: John Reiser
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    John Reiser
     
  • The state of the function pair tracing_stop()/tracing_start() is
    correctly considered when tracer data are updated. However, the global
    and externally accessible variable tracing_max_latency is always updated
    - even when tracing is stopped.

    The update should only occur, if tracing was not stopped.

    Signed-off-by: Carsten Emde
    Signed-off-by: Steven Rostedt

    Carsten Emde
     
  • When the nsecs_to_usecs() conversion in probe_wakeup_sched_switch() and
    check_critical_timing() was moved to a later stage in order to avoid
    unnecessary computing, it was overlooked to remove the original
    variables, assignments and comments..

    Signed-off-by: Carsten Emde
    Signed-off-by: Steven Rostedt

    Carsten Emde
     
  • Booting 2.6.31 and executing
    echo 1 >/sys/kernel/debug/tracing/events/enable
    leads to
    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [] ftrace_raw_event_block_bio_bounce+0x4b/0xb9

    Apparently,
    bio = bio_map_user(q, NULL, uaddr, len, reading, gfp_mask);
    is called in block/blk-map.c:58 where bio->bi_bdev in set to NULL and
    still is NULL when an attempt is made to evaluate bio->bi_bdev->bd_dev
    in include/trace/events/block.h:189.

    The tracepoint should ensure bio->bi_bdev is not dereferenced, if NULL.

    Signed-off-by: Carsten Emde
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Carsten Emde
     

12 Sep, 2009

5 commits

  • Convert the writing to 'set_graph_function', 'set_ftrace_filter'
    and 'set_ftrace_notrace' to use the generic trace_parser
    'trace_get_user' function.

    Removed FTRACE_ITER_CONT flag, since it's not needed after this change.

    Minor fix in set_graph_function display - g_show function.

    Signed-off-by: Jiri Olsa
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    jolsa@redhat.com
     
  • Convert the parsing of the file 'set_event' to use the generic
    trace_praser 'trace_get_user' function.

    Signed-off-by: Jiri Olsa
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    jolsa@redhat.com
     
  • Create a "trace_parser" that can parse the user space input for
    separate words.

    struct trace_parser is the descriptor.

    Generic "trace_get_user" function that can be a helper to read multiple
    words passed in by user space.

    Signed-off-by: Jiri Olsa
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    jolsa@redhat.com
     
  • Both trace_output.c and trace_function_graph.c do basically the same
    thing to handle the printing of the latency-format. This patch moves
    the code into one function that both can use.

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • This patch adds the lock depth of the big kernel lock to the generic
    entry header. This way we can see the depth of the lock and help
    in removing the BKL.

    Example:

    # _------=> CPU#
    # / _-----=> irqs-off
    # | / _----=> need-resched
    # || / _---=> hardirq/softirq
    # ||| / _--=> preempt-depth
    # |||| /_--=> lock-depth
    # |||||/ delay
    # cmd pid |||||| time | caller
    # \ / |||||| \ | /
    -0 2.N..3 5902255250us+: lock_acquire: read rcu_read_lock
    -0 2.N..3 5902255253us+: lock_release: rcu_read_lock
    -0 2dN..3 5902255257us+: lock_acquire: xtime_lock
    -0 2dN..4 5902255259us : lock_acquire: clocksource_lock
    -0 2dN..4 5902255261us+: lock_release: clocksource_lock

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

11 Sep, 2009

3 commits

  • The userstack trace required the recording of the tgid entry.
    Unfortunately, it was added to the generic entry where it wasted
    4 bytes of every entry and was only used by one entry.

    This patch moves it out of the generic field and moves it into the
    only user (userstack_entry).

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • While debugging something with the function_graph tracer, I found the
    need to see the preempt count of the traces. Unfortunately, since
    the function graph tracer has its own output formatting, it does not
    honor the latency-format option.

    This patch makes the function_graph tracer honor the latency-format
    option, but still keeps control of the output. But now we have the
    same details that the latency-format supplies.

    # tracer: function_graph
    #
    # _-----=> irqs-off
    # / _----=> need-resched
    # | / _---=> hardirq/softirq
    # || / _--=> preempt-depth
    # ||| /
    # ||||
    # CPU|||| DURATION FUNCTION CALLS
    # | |||| | | | | | |
    3) d..1 1.333 us | idle_cpu();
    3) d.h1 | tick_check_idle() {
    3) d.h1 0.550 us | tick_check_oneshot_broadcast();
    3) d.h1 | tick_nohz_stop_idle() {
    3) d.h1 | ktime_get() {
    3) d.h1 | ktime_get_ts() {

    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • The dynamic function tracer relys on the macro P6_NOP5 always being
    an atomic NOP. If for some reason it is changed to be two operations
    (like a nop2 nop3) it can faults within the kernel when the function
    tracer modifies the code.

    This patch adds a comment to note that the P6_NOPs are expected to
    be atomic. This will hopefully prevent anyone from changing that.

    Reported-by: Mathieu Desnoyer
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     

10 Sep, 2009

6 commits

  • Move DEFINE_COMPARISON_PRED() and DEFINE_EQUALITY_PRED()
    to kernel/trace/trace_events_filter.c

    Signed-off-by: Li Zefan
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Li Zefan
     
  • Remove unused field @stats from struct tracer.

    Signed-off-by: Li Zefan
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Li Zefan
     
  • Fix white-space formatting.

    Signed-off-by: Li Zefan
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Li Zefan
     
  • Removes unreachable code.

    Signed-off-by: Li Zefan
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Li Zefan
     
  • The wakeup tracer, when enabled, has its own function tracer.
    It only traces the functions on the CPU where the task it is following
    is on. If a task is woken on one CPU but then migrates to another CPU
    before it wakes up, the latency tracer will then start tracing functions
    on the other CPU.

    To find which CPU the task is on, the wakeup function tracer performs
    a task_cpu(wakeup_task). But to make sure the task does not disappear
    it grabs the wakeup_lock, which is also taken when the task wakes up.
    By taking this lock, the function tracer does not need to worry about
    the task being freed as it checks its cpu.

    Jan Blunck found a problem with this approach on his 32 CPU box. When
    a task is being traced by the wakeup tracer, all functions take this
    lock. That means that on all 32 CPUs, each function call is taking
    this one lock to see if the task is on that CPU. This lock has just
    serialized all functions on all 32 CPUs. Needless to say, this caused
    major issues on that box. It would even lockup.

    This patch changes the wakeup latency to insert a probe on the migrate task
    tracepoint. When a task changes its CPU that it will run on, the
    probe will take note. Now the wakeup function tracer no longer needs
    to take the lock. It only compares the current CPU with a variable that
    holds the current CPU the task is on. We don't worry about races since
    it is OK to add or miss a function trace.

    Reported-by: Jan Blunck
    Tested-by: Jan Blunck
    Signed-off-by: Steven Rostedt

    Steven Rostedt
     
  • rb_buffer_peek() operates with struct ring_buffer_per_cpu *cpu_buffer
    only. Thus, instead of passing variables buffer and cpu it is better
    to use cpu_buffer directly. This also reduces the risk of races since
    cpu_buffer is not calculated twice.

    Signed-off-by: Robert Richter
    LKML-Reference:
    Signed-off-by: Steven Rostedt

    Robert Richter
     

06 Sep, 2009

17 commits