1. 23 Dec, 2011 5 commits
    • Nelson Elhage's avatar
      perf: builtin-record: Provide advice if mmap'ing fails with EPERM. · 18e60939
      Nelson Elhage authored
      This failure is most likely due to running up against the
      kernel.perf_event_mlock_kb sysctl, so we can tell the user what to do to
      fix the issue.
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1324301972-22740-3-git-send-email-nelhage@nelhage.comSigned-off-by: default avatarNelson Elhage <nelhage@nelhage.com>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      18e60939
    • Ingo Molnar's avatar
      perf tools: Fix truncated annotation · f41612f4
      Ingo Molnar authored
      I get such truncated annotation results in 'perf top':
      
               :        Disassembly of section .text:                                                   ▒
               :                                                                                        ▒
               :        ffffffff810966a8 <nr_iowait_cpu>:                                               ▒
          4.94 :        ffffffff810966a8:       movslq %edi,%rdi                                        ▒
          3.70 :        ffffffff810966ab:       mov    $0x13700,%rax                                    ▒
          0.00 :        ffffffff810966b2:       add    -0x7e32cb00(,%rdi,8),%rax                        ▒
          8.64 :        ffffffff810966ba:       mov    0x7e0(%rax),%eax                                 ▒
         82.72 :        ffffffff810966c0:       cltq                                                    ▒
      
      Note the missing 'retq' which is there in the original function:
      
      ffffffff810966a8 <nr_iowait_cpu>:
      ffffffff810966a8:       48 63 ff                movslq %edi,%rdi
      ffffffff810966ab:       48 c7 c0 00 37 01 00    mov    $0x13700,%rax
      ffffffff810966b2:       48 03 04 fd 00 35 cd    add    -0x7e32cb00(,%rdi,8),%rax
      ffffffff810966b9:       81
      ffffffff810966ba:       8b 80 e0 07 00 00       mov    0x7e0(%rax),%eax
      ffffffff810966c0:       48 98                   cltq
      ffffffff810966c2:       c3                      retq
      
      ffffffff810966c3 <this_cpu_load>:
      
      I'm using a fairly recent binutils:
      
        GNU objdump version 2.21.51.0.6-2.fc16 20110118
      
      AFAICS the bug is simply that sym->end points to the last byte
      of the symbol in question - while objdump's --stop-address
      expects the last byte plus 1 to disassemble the full range.
      
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20111223130804.GA24305@elte.huSigned-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      f41612f4
    • David Ahern's avatar
      perf script: look up thread using tid instead of pid · 64aab93c
      David Ahern authored
      This allows the thread name to be dispalyed when dumping
      events:
                 myapp 25118 [000] 450385.538815: context-switches ...
          myapp:worker 25119 [000] 450385.538894: context-switches ...
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1324578603-12762-4-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>
      64aab93c
    • David Ahern's avatar
      perf tools: Look up thread names for system wide profiling · f5faf726
      David Ahern authored
      This handles multithreaded processes with named threads when doing
      system wide profiling: the comm for each thread is looked up allowing
      them to be different from the thread group leader.
      
      v2:
      - fixed sizeof arg to perf_event__get_comm_tgid
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1324578603-12762-3-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>
      f5faf726
    • David Ahern's avatar
      perf tools: Fix comm for processes with named threads · defd8d38
      David Ahern authored
      perf does not properly handle monitoring of processes with named threads.
      For example:
      
      $ ps -C myapp -L
        PID   LWP TTY          TIME CMD
      25118 25118 ?        00:00:00 myapp
      25118 25119 ?        00:00:00 myapp:worker
      
      perf record -e cs -c 1 -fo /tmp/perf.data -p 25118 -- sleep 10
      perf report --stdio -i /tmp/perf.data
         100.00%  myapp:worker  [kernel.kallsyms]  [k] perf_event_task_sched_out
      
      The process name is set to the name of the last thread it finds for the
      process.
      
      The Problem:
      perf-top and perf-record both create a thread_map of threads to be
      monitored. That map is used in perf_event__synthesize_thread_map which
      loops over the entries in thread_map and calls __event__synthesize_thread
      to generate COMM and MMAP events.
      
      __event__synthesize_thread calls perf_event__synthesize_comm which opens
      /proc/pid/status, reads the name of the task and its thread group id.
      That's all fine. The problem is that it then reads /proc/pid/task and
      generates COMM events for each task it finds - but using the name found
      in /proc/pid/status where pid is the thread of interest.
      
      The end result (looping over thread_map + synthesizing comm events for
      each thread each time) means the name of the last thread processed sets
      the name for all threads in the process - which is not good for
      multithreaded processes with named threads.
      
      The Fix:
      perf_event__synthesize_comm has an input argument (full) that decides
      whether to process task entries for each pid it is passed. It currently
      never set to 0 (perf_event__synthesize_comm has a single caller and it
      always passes the value 1). Let's fix that.
      
      Add the full input argument to __event__synthesize_thread which passes
      it to perf_event__synthesize_comm. For thread/process monitoring set full
      to 0 which means COMM and MMAP events are only generated for the pid
      passed to it. For system wide monitoring set full to 1 so that COMM events
      are generated for all threads in a process.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1324578603-12762-2-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>
      defd8d38
  2. 22 Dec, 2011 1 commit
  3. 21 Dec, 2011 4 commits
  4. 20 Dec, 2011 13 commits
  5. 17 Dec, 2011 1 commit
  6. 16 Dec, 2011 16 commits