1. 15 1月, 2009 2 次提交
  2. 14 1月, 2009 1 次提交
  3. 11 1月, 2009 1 次提交
    • F
      tracing/ftrace: handle more than one stat file per tracer · 034939b6
      Frederic Weisbecker 提交于
      Impact: new API for tracers
      
      Make the stat tracing API reentrant. And also provide the new directory
      /debugfs/tracing/trace_stat which will contain all the stat files for the
      current active tracer.
      
      Now a tracer will, if desired, want to provide a zero terminated array of
      tracer_stat structures.
      Each one contains the callbacks necessary for one stat file.
      It have to provide at least a name for its stat file, an iterator with
      stat_start/start_next callback and an output callback for one stat entry.
      
      Also adapt the branch tracer to this new API.
      We create two files "all" and "annotated" inside the /debugfs/tracing/trace_stat
      directory, making the both stats simultaneously available instead of needing
      to change an option to switch from one stat file to another.
      
      The output of these stats haven't changed.
      
      Changes in v2:
      
      _ Apply the previous memory leak fix (rebase against tip/master)
      
      Changes in v3:
      
      _ Merge the patch that adapted the branch tracer to this Api in this patch to
        not break the kernel build.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NSteven Rostedt <srostedt@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      034939b6
  4. 07 1月, 2009 2 次提交
  5. 29 12月, 2008 1 次提交
    • F
      tracing/ftrace: provide the base infrastructure for histogram tracing · dbd0b4b3
      Frederic Weisbecker 提交于
      Impact: extend the tracing API
      
      The goal of this patch is to normalize and make more easy the
      implementation of statistical (histogram) tracing.
      
      It implements a trace_stat file into the /debugfs/tracing directory where
      one can print a one-shot output of statistics/histogram entries.
      
      A tracer has to provide two basic iterator callbacks:
      
        stat_start() => the first entry
        stat_next(prev, idx) => the next one.
      
      Note that it is adapted for arrays or hash tables or lists.... since it
      provides a pointer to the previous entry and the current index of the
      iterator.
      
      These two callbacks are called to get a snapshot of the statistics at each
      opening of the trace_stat file because. The values are so updated between
      two "cat trace_stat". And the tracer is free to lock its datas during the
      iteration to keep consistent values.
      
      Since it is almost always interesting to sort statisticals values to
      address the problems by priority, this infrastructure provides a "sorting"
      of the stat entries too if desired. A tracer has just to provide a
      stat_cmp callback to compare two entries and the stat tracing
      infrastructure will build a sorted list of the given entries.
      
      A last callback, called stat_headers, can be implemented by a tracer to
      output headers on its trace.
      
      If one of these callbacks is changed on runtime, it just have to signal it
      to the stat tracing API by calling the init_tracer_stat() helper.
      
      Changes in V2:
      
      - Fix a memory leak if the user opens multiple times the trace_stat file
        without closing it. Now we always free our list before rebuilding it.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dbd0b4b3