1. 22 2月, 2012 2 次提交
    • J
      ftrace: Add enable/disable ftrace_ops control interface · e248491a
      Jiri Olsa 提交于
      Adding a way to temporarily enable/disable ftrace_ops. The change
      follows the same way as 'global' ftrace_ops are done.
      
      Introducing 2 global ftrace_ops - control_ops and ftrace_control_list
      which take over all ftrace_ops registered with FTRACE_OPS_FL_CONTROL
      flag. In addition new per cpu flag called 'disabled' is also added to
      ftrace_ops to provide the control information for each cpu.
      
      When ftrace_ops with FTRACE_OPS_FL_CONTROL is registered, it is
      set as disabled for all cpus.
      
      The ftrace_control_list contains all the registered 'control' ftrace_ops.
      The control_ops provides function which iterates ftrace_control_list
      and does the check for 'disabled' flag on current cpu.
      
      Adding 3 inline functions:
        ftrace_function_local_disable/ftrace_function_local_enable
        - enable/disable the ftrace_ops on current cpu
        ftrace_function_local_disabled
        - get disabled ftrace_ops::disabled value for current cpu
      
      Link: http://lkml.kernel.org/r/1329317514-8131-2-git-send-email-jolsa@redhat.comAcked-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      e248491a
    • S
      tracing: Don't use p->len field to determine output in __print_*() functions · 5b349261
      Steven Rostedt 提交于
      If more than one __print_*() function is used in a tracepoint
      (__print_flags(), __print_symbols(), etc), then the temp seq buffer will
      not be zero on entry. Using the temp seq buffer's length to know if
      data has been printed or not in the current function is incorrect and
      may produce incorrect results.
      
      Currently, no in-tree tracepoint causes this bug, but new ones may
      be created.
      
      Cc: Andrew Vagin <avagin@openvz.org>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      5b349261
  2. 21 2月, 2012 1 次提交
  3. 17 2月, 2012 2 次提交
  4. 15 2月, 2012 2 次提交
  5. 14 2月, 2012 16 次提交
  6. 13 2月, 2012 5 次提交
  7. 11 2月, 2012 4 次提交
  8. 09 2月, 2012 2 次提交
    • D
      perf record: No build id option fails · d3665498
      David Ahern 提交于
      A recent refactoring of perf-record introduced the following:
      
      perf record -a -B
      Couldn't generating buildids. Use --no-buildid to profile anyway.
      sleep: Terminated
      
      I believe the triple negative was meant to be only a double negative.
      :-) While I'm there, fixed the grammar on the error message.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/1328567272-13190-1-git-send-email-dsahern@gmail.comSigned-off-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d3665498
    • S
      perf tools: fix endianness detection in perf.data · 73323f54
      Stephane Eranian 提交于
      The current version of perf detects whether or not the perf.data file is
      written in a different endianness using the attr_size field in the
      header of the file. This field represents sizeof(struct perf_event_attr)
      as known to perf record. If the sizes do not match, then perf tries the
      byte-swapped version. If they match, then the tool assumes a different
      endianness.
      
      The issue with the approach is that it assumes the size of
      perf_event_attr always has to match between perf record and perf report.
      However, the kernel perf_event ABI is extensible.  New fields can be
      added to struct perf_event_attr. Consequently, it is not possible to use
      attr_size to detect endianness.
      
      This patch takes another approach by using the magic number written at
      the beginning of the perf.data file to detect endianness. The magic
      number is an eight-byte signature.  It's primary purpose is to identify
      (signature) a perf.data file. But it could also be used to encode the
      endianness.
      
      The patch introduces a new value for this signature. The key difference
      is that the signature is written differently in the file depending on
      the endianness. Thus, by comparing the signature from the file with the
      tool's own signature it is possible to detect endianness. The new
      signature is "PERFILE2".
      
      Backward compatiblity with existing perf.data file is ensured.
      Tested-by: NDavid Ahern <dsahern@gmail.com>
      Acked-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
      Cc: Arun Sharma <asharma@fb.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Lin Ming <ming.m.lin@intel.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Roberto Agostino Vitillo <ravitillo@lbl.gov>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Vince Weaver <vweaver1@eecs.utk.edu>
      Link: http://lkml.kernel.org/r/1328187288-24395-15-git-send-email-eranian@google.comSigned-off-by: NStephane Eranian <eranian@google.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      73323f54
  9. 07 2月, 2012 6 次提交