1. 23 Feb, 2012 1 commit
    • David Smith's avatar
      tracepoint, vfs, sched: Add exec() tracepoint · 4ff16c25
      David Smith authored
      Added a minimal exec tracepoint. Exec is an important major event
      in the life of a task, like fork(), clone() or exit(), all of
      which we already trace.
      
      [ We also do scheduling re-balancing during exec() - so it's useful
        from a scheduler instrumentation POV as well. ]
      
      If you want to watch a task start up, when it gets exec'ed is a good place
      to start.  With the addition of this tracepoint, exec's can be monitored
      and better picture of general system activity can be obtained. This
      tracepoint will also enable better process life tracking, allowing you to
      answer questions like "what process keeps starting up binary X?".
      
      This tracepoint can also be useful in ftrace filtering and trigger
      conditions: i.e. starting or stopping filtering when exec is called.
      Signed-off-by: default avatarDavid Smith <dsmith@redhat.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Link: http://lkml.kernel.org/r/4F314D19.7030504@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      4ff16c25
  2. 22 Feb, 2012 1 commit
  3. 21 Feb, 2012 1 commit
    • Stephane Eranian's avatar
      perf tools: fix broken perf record -a mode · 6b1bee90
      Stephane Eranian authored
      The following commit:
      b52956c9 perf tools: Allow multiple threads or processes in record, stat, top
      
      introduced a bug in the thread_map code which caused perf record -a to
      not setup system-wide monitoring properly.
      
      $ taskset -c 1 noploop 1000 &
      $ perf record -a -C 1 sleep 10
      $ perf report -D | tail -20
      cycles stats:
                 TOTAL events:       4413
                  MMAP events:       4025
                  COMM events:        340
                SAMPLE events:         48
      
      Here I was expecting about 10,000 samples and not 48.
      
      In system-wide mode, the PID passed to perf_event_open() must be -1 and
      it was 0. That caused the kernel to setup a per-process event on PID:0.
      Consequently, the number of samples captured does not correspond to the
      requested measurement.
      
      The following one-liner fixes the problem for me with or without -C.
      
      I would also suggest to change the malloc() to something that matches
      the struct definition. thread_map->map[] is declared as int map[] and
      not pid_t map[]. If map[] can only contain pids, then change the struct
      definition.
      Acked-by: default avatarDavid Ahern <dsahern@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20120221145424.GA6757@quadSigned-off-by: default avatarStephane Eranian <eranian@google.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      6b1bee90
  4. 17 Feb, 2012 4 commits
  5. 14 Feb, 2012 15 commits
  6. 13 Feb, 2012 8 commits
  7. 11 Feb, 2012 4 commits
  8. 09 Feb, 2012 2 commits
    • David Ahern's avatar
      perf record: No build id option fails · d3665498
      David Ahern authored
      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: default avatarDavid Ahern <dsahern@gmail.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      d3665498
    • Stephane Eranian's avatar
      perf tools: fix endianness detection in perf.data · 73323f54
      Stephane Eranian authored
      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: default avatarDavid Ahern <dsahern@gmail.com>
      Acked-by: default avatarDavid 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: default avatarStephane Eranian <eranian@google.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      73323f54
  9. 07 Feb, 2012 3 commits
  10. 06 Feb, 2012 1 commit
    • Namhyung Kim's avatar
      perf stat: Align scaled output of cpu-clock · 9dac6a29
      Namhyung Kim authored
      The output of cpu-clock event is controlled in nsec_printout(),
      but its alignment was broken:
      
       Performance counter stats for 'sleep 1':
      
               6,038,774 instructions              #    0.00  insns per cycle
                     180 faults                    #    0.007 K/sec                   [99.95%]
               1,282,201 branches                  #    0.053 M/sec                   [99.84%]
            24126.221811 cpu-clock                 [99.62%]
            24121.689540 task-clock                #   24.098 CPUs utilized           [99.52%]
      
             1.001001017 seconds time elapsed
      
      This patch fixes this:
      
       Performance counter stats for 'sleep 1':
      
              13,540,843 instructions              #    0.00  insns per cycle
                     180 faults                    #    0.007 K/sec                   [99.94%]
               2,875,386 branches                  #    0.119 M/sec                   [99.82%]
            24144.221137 cpu-clock                                                    [99.61%]
            24133.515366 task-clock                #   24.109 CPUs utilized           [99.52%]
      
             1.001020946 seconds time elapsed
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1328514285-26232-2-git-send-email-namhyung.kim@lge.comSigned-off-by: default avatarNamhyung Kim <namhyung.kim@lge.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      9dac6a29