1. 18 8月, 2011 1 次提交
  2. 25 7月, 2011 1 次提交
  3. 21 7月, 2011 1 次提交
  4. 28 5月, 2011 1 次提交
  5. 26 5月, 2011 1 次提交
    • A
      perf symbols: Handle /proc/sys/kernel/kptr_restrict · ec80fde7
      Arnaldo Carvalho de Melo 提交于
      Perf uses /proc/modules to figure out where kernel modules are loaded.
      
      With the advent of kptr_restrict, non root users get zeroes for all module
      start addresses.
      
      So check if kptr_restrict is non zero and don't generate the syntethic
      PERF_RECORD_MMAP events for them.
      
      Warn the user about it in perf record and in perf report.
      
      In perf report the reference relocation symbol being zero means that
      kptr_restrict was set, thus /proc/kallsyms has only zeroed addresses, so don't
      use it to fixup symbol addresses when using a valid kallsyms (in the buildid
      cache) or vmlinux (in the vmlinux path) build-id located automatically or
      specified by the user.
      
      Provide an explanation about it in 'perf report' if kernel samples were taken,
      checking if a suitable vmlinux or kallsyms was found/specified.
      
      Restricted /proc/kallsyms don't go to the buildid cache anymore.
      
      Example:
      
       [acme@emilia ~]$ perf record -F 100000 sleep 1
      
       WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted, check
       /proc/sys/kernel/kptr_restrict.
      
       Samples in kernel functions may not be resolved if a suitable vmlinux file is
       not found in the buildid cache or in the vmlinux path.
      
       Samples in kernel modules won't be resolved at all.
      
       If some relocation was applied (e.g. kexec) symbols may be misresolved even
       with a suitable vmlinux or kallsyms file.
      
       [ perf record: Woken up 1 times to write data ]
       [ perf record: Captured and wrote 0.005 MB perf.data (~231 samples) ]
       [acme@emilia ~]$
      
       [acme@emilia ~]$ perf report --stdio
       Kernel address maps (/proc/{kallsyms,modules}) were restricted,
       check /proc/sys/kernel/kptr_restrict before running 'perf record'.
      
       If some relocation was applied (e.g. kexec) symbols may be misresolved.
      
       Samples in kernel modules can't be resolved as well.
      
       # Events: 13  cycles
       #
       # Overhead  Command      Shared Object                 Symbol
       # ........  .......  .................  .....................
       #
          20.24%    sleep  [kernel.kallsyms]  [k] page_fault
          20.04%    sleep  [kernel.kallsyms]  [k] filemap_fault
          19.78%    sleep  [kernel.kallsyms]  [k] __lru_cache_add
          19.69%    sleep  ld-2.12.so         [.] memcpy
          14.71%    sleep  [kernel.kallsyms]  [k] dput
           4.70%    sleep  [kernel.kallsyms]  [k] flush_signal_handlers
           0.73%    sleep  [kernel.kallsyms]  [k] perf_event_comm
           0.11%    sleep  [kernel.kallsyms]  [k] native_write_msr_safe
      
       #
       # (For a higher level overview, try: perf report --sort comm,dso)
       #
       [acme@emilia ~]$
      
      This is because it found a suitable vmlinux (build-id checked) in
      /lib/modules/2.6.39-rc7+/build/vmlinux (use -v in perf report to see the long
      file name).
      
      If we remove that file from the vmlinux path:
      
       [root@emilia ~]# mv /lib/modules/2.6.39-rc7+/build/vmlinux \
      		     /lib/modules/2.6.39-rc7+/build/vmlinux.OFF
       [acme@emilia ~]$ perf report --stdio
       [kernel.kallsyms] with build id 57298cdbe0131f6871667ec0eaab4804dcf6f562
       not found, continuing without symbols
      
       Kernel address maps (/proc/{kallsyms,modules}) were restricted, check
       /proc/sys/kernel/kptr_restrict before running 'perf record'.
      
       As no suitable kallsyms nor vmlinux was found, kernel samples can't be
       resolved.
      
       Samples in kernel modules can't be resolved as well.
      
       # Events: 13  cycles
       #
       # Overhead  Command      Shared Object  Symbol
       # ........  .......  .................  ......
       #
          80.31%    sleep  [kernel.kallsyms]  [k] 0xffffffff8103425a
          19.69%    sleep  ld-2.12.so         [.] memcpy
      
       #
       # (For a higher level overview, try: perf report --sort comm,dso)
       #
       [acme@emilia ~]$
      Reported-by: NStephane Eranian <eranian@google.com>
      Suggested-by: NDavid Miller <davem@davemloft.net>
      Cc: Dave Jones <davej@redhat.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Kees Cook <kees.cook@canonical.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Link: http://lkml.kernel.org/n/tip-mt512joaxxbhhp1odop04yit@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ec80fde7
  6. 15 5月, 2011 1 次提交
    • A
      perf evlist: Fix per thread mmap setup · aece948f
      Arnaldo Carvalho de Melo 提交于
      The PERF_EVENT_IOC_SET_OUTPUT ioctl was returning -EINVAL when using
      --pid when monitoring multithreaded apps, as we can only share a ring
      buffer for events on the same thread if not doing per cpu.
      
      Fix it by using per thread ring buffers.
      
      Tested with:
      
      [root@felicio ~]# tuna -t 26131 -CP | nl
        1                      thread       ctxt_switches
        2    pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
        3 26131   OTHER     0      0,1  10814276      2397830 chromium-browse
        4  642    OTHER     0      0,1     14688            0 chromium-browse
        5  26148  OTHER     0      0,1    713602       115479 chromium-browse
        6  26149  OTHER     0      0,1    801958         2262 chromium-browse
        7  26150  OTHER     0      0,1   1271128          248 chromium-browse
        8  26151  OTHER     0      0,1         3            0 chromium-browse
        9  27049  OTHER     0      0,1     36796            9 chromium-browse
       10  618    OTHER     0      0,1     14711            0 chromium-browse
       11  661    OTHER     0      0,1     14593            0 chromium-browse
       12  29048  OTHER     0      0,1     28125            0 chromium-browse
       13  26143  OTHER     0      0,1   2202789          781 chromium-browse
      [root@felicio ~]#
      
      So 11 threads under pid 26131, then:
      
      [root@felicio ~]# perf record -F 50000 --pid 26131
      
      [root@felicio ~]# grep perf_event /proc/`pidof perf`/maps | nl
        1 7fa4a2538000-7fa4a25b9000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
        2 7fa4a25b9000-7fa4a263a000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
        3 7fa4a263a000-7fa4a26bb000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
        4 7fa4a26bb000-7fa4a273c000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
        5 7fa4a273c000-7fa4a27bd000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
        6 7fa4a27bd000-7fa4a283e000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
        7 7fa4a283e000-7fa4a28bf000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
        8 7fa4a28bf000-7fa4a2940000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
        9 7fa4a2940000-7fa4a29c1000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
       10 7fa4a29c1000-7fa4a2a42000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
       11 7fa4a2a42000-7fa4a2ac3000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
      [root@felicio ~]#
      
      11 mmaps, one per thread since we didn't specify any CPU list, so we need one
      mmap per thread and:
      
      [root@felicio ~]# perf record -F 50000 --pid 26131
      ^M
      ^C[ perf record: Woken up 79 times to write data ]
      [ perf record: Captured and wrote 20.614 MB perf.data (~900639 samples) ]
      
      [root@felicio ~]# perf report -D | grep PERF_RECORD_SAMPLE | cut -d/ -f2 | cut -d: -f1 | sort -n | uniq -c | sort -nr | nl
           1	 371310 26131
           2	  96516 26148
           3	  95694 26149
           4	  95203 26150
           5	   7291 26143
           6	     87 27049
           7	     76 661
           8	     60 29048
           9	     47 618
          10	     43 642
      [root@felicio ~]#
      
      Ok, one of the threads, 26151 was quiescent, so no samples there, but all the
      others are there.
      
      Then, if I specify one CPU:
      
      [root@felicio ~]# perf record -F 50000 --pid 26131 --cpu 1
      ^C[ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.680 MB perf.data (~29730 samples) ]
      
      [root@felicio ~]# perf report -D | grep PERF_RECORD_SAMPLE | cut -d/ -f2 | cut -d: -f1 | sort -n | uniq -c | sort -nr | nl
           1	   8444 26131
           2	   2584 26149
           3	   2518 26148
           4	   2324 26150
           5	    123 26143
           6	      9 661
           7	      9 29048
      [root@felicio ~]#
      
      This machine has two cores, so fewer threads appeared on the radar, and:
      
      [root@felicio ~]# grep perf_event /proc/`pidof perf`/maps | nl
       1 7f484b922000-7f484b9a3000 rwxs 00000000 00:09 4064 anon_inode:[perf_event]
      [root@felicio ~]#
      
      Just one mmap, as now we can use just one per-cpu buffer instead of the
      per-thread needed in the previous case.
      
      For global profiling:
      
      [root@felicio ~]# perf record -F 50000 -a
      ^C[ perf record: Woken up 26 times to write data ]
      [ perf record: Captured and wrote 7.128 MB perf.data (~311412 samples) ]
      
      [root@felicio ~]# grep perf_event /proc/`pidof perf`/maps | nl
           1	7fb49b435000-7fb49b4b6000 rwxs 00000000 00:09 4064                       anon_inode:[perf_event]
           2	7fb49b4b6000-7fb49b537000 rwxs 00000000 00:09 4064                       anon_inode:[perf_event]
      [root@felicio ~]#
      
      It uses per-cpu buffers.
      
      For just one thread:
      
      [root@felicio ~]# perf record -F 50000 --tid 26148
      ^C[ perf record: Woken up 2 times to write data ]
      [ perf record: Captured and wrote 0.330 MB perf.data (~14426 samples) ]
      
      [root@felicio ~]# perf report -D | grep PERF_RECORD_SAMPLE | cut -d/ -f2 | cut -d: -f1 | sort -n | uniq -c | sort -nr | nl
           1	   9969 26148
      [root@felicio ~]#
      
      [root@felicio ~]# grep perf_event /proc/`pidof perf`/maps | nl
           1	7f286a51b000-7f286a59c000 rwxs 00000000 00:09 4064                       anon_inode:[perf_event]
      [root@felicio ~]#
      Tested-by: NDavid Ahern <dsahern@gmail.com>
      Tested-by: NLin Ming <ming.m.lin@intel.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Link: http://lkml.kernel.org/r/20110426204401.GB1746@ghostprotocols.netSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      aece948f
  7. 15 4月, 2011 1 次提交
  8. 31 3月, 2011 1 次提交
    • F
      perf: mmap 512 kiB by default · 800cd25c
      Frederic Weisbecker 提交于
      The default setting of perf record is to mmap 128 pages if the user
      did not override with -m.
      
      However the page size may vary accross different architecture
      settings, giving different default size between each.
      
      Moreover the kernel side still has a default max number of mlocked
      pages of 512 kiB + 1 page for unprivileged users. 128 + 1 pages
      with page size > 4096 overlaps this threshold.
      
      Thus, better adapt to this limitation and set the default number of
      pages to fit those 512 kiB + 1 page.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Stephane Eranian <eranian@google.com>
      LKML-Reference: <1301535324-9735-1-git-send-email-fweisbec@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      800cd25c
  9. 30 3月, 2011 2 次提交
    • D
      perf tools: Emit clearer message for sys_perf_event_open ENOENT return · ca6a4258
      David Ahern 提交于
      Resend of patch sent back in January 2011 in light of recent confusion around
      unsupported events for a given platform.
      
      Improve sys_perf_event_open ENOENT return handling in top and record, just
      like 5a3446bc does for stat.
      
      Retry of Arnaldo's patch using ui_warning instead of die which allows the
      fallback from hardware cycles to software clock.
      
      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: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      LKML-Reference: <1301080271-20945-1-git-send-email-daahern@cisco.com>
      Signed-off-by: NDavid Ahern <daahern@cisco.com>
      [ committer note: Some adjustments to make it apply to newer codebase ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ca6a4258
    • A
      perf tools: Fixup exit path when not able to open events · c286c419
      Arnaldo Carvalho de Melo 提交于
      We have to deal with the TUI mode in perf top, so that we don't end up
      with a garbled screen when, say, a non root user on a machine with a
      paranoid setting (the default) tries to use 'perf top'.
      
      Introduce a ui__warning_paranoid() routine shared by top and record that
      tells the user the valid values for /proc/sys/kernel/perf_event_paranoid.
      
      Cc: David Ahern <daahern@cisco.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c286c419
  10. 10 3月, 2011 1 次提交
    • A
      perf session: Use evlist/evsel for managing perf.data attributes · a91e5431
      Arnaldo Carvalho de Melo 提交于
      So that we can reuse things like the id to attr lookup routine
      (perf_evlist__id2evsel) that uses a hash table instead of the linear
      lookup done in the older perf_header_attr routines, etc.
      
      Also to make evsels/evlist more pervasive an API, simplyfing using the
      emerging perf lib.
      
      cc: Arun Sharma <arun@sharma-home.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a91e5431
  11. 02 3月, 2011 1 次提交
    • F
      perf: Set filters before mmaping events · 0a102479
      Frederic Weisbecker 提交于
      We currently set the filters after we mmap the events, this is a
      race that let undesired events record themselves in the buffer before
      we had the time to set the filters.
      
      So set the filters before they can be recorded. That also librarizes
      the filters setting so that filtering can be done more easily
      from other tools than perf record later.
      Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      0a102479
  12. 17 2月, 2011 1 次提交
    • A
      perf record: Delay setting the header writing atexit call · 712a4b60
      Arnaldo Carvalho de Melo 提交于
      While testing the --filter option I noticed that we were writing lots of
      unneeded stuff to the perf.data header when the filter ioctl fails, so
      move the atexit(atexit_header) call to after we create the counters
      successfully.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      712a4b60
  13. 16 2月, 2011 1 次提交
    • S
      perf tool: Add cgroup support · 023695d9
      Stephane Eranian 提交于
      This patch adds the ability to filter monitoring based on container groups
      (cgroups) for both perf stat and perf record. It is possible to monitor
      multiple cgroup in parallel. There is one cgroup per event. The cgroups to
      monitor are passed via a new -G option followed by a comma separated list of
      cgroup names.
      
      The cgroup filesystem has to be mounted. Given a cgroup name, the perf tool
      finds the corresponding directory in the cgroup filesystem and opens it. It
      then passes that file descriptor to the kernel.
      
      Example:
      
      $ perf stat -B -a -e cycles:u,cycles:u,cycles:u -G test1,,test2 -- sleep 1
       Performance counter stats for 'sleep 1':
      
            2,368,667,414  cycles                   test1
            2,369,661,459  cycles
            <not counted>  cycles                   test2
      
              1.001856890  seconds time elapsed
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      LKML-Reference: <4d590290.825bdf0a.7d0a.4890@mx.google.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      023695d9
  14. 10 2月, 2011 1 次提交
    • A
      perf tools: Fix thread_map event synthesizing in top and record · 401b8e13
      Arnaldo Carvalho de Melo 提交于
      Jeff Moyer reported these messages:
      
        Warning:  ... trying to fall back to cpu-clock-ticks
      
      couldn't open /proc/-1/status
      couldn't open /proc/-1/maps
      [ls output]
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.008 MB perf.data (~363 samples) ]
      
      That lead me and David Ahern to see that something was fishy on the thread
      synthesizing routines, at least for the case where the workload is started
      from 'perf record', as -1 is the default for target_tid in 'perf record --tid'
      parameter, so somehow we were trying to synthesize the PERF_RECORD_MMAP and
      PERF_RECORD_COMM events for the thread -1, a bug.
      
      So I investigated this and noticed that when we introduced support for
      recording a process and its threads using --pid some bugs were introduced and
      that the way to fix it was to instead of passing the target_tid to the event
      synthesizing routines we should better pass the thread_map that has the list of
      threads for a --pid or just the single thread for a --tid.
      
      Checked in the following ways:
      
      On a 8-way machine run cyclictest:
      
      [root@emilia ~]# perf record cyclictest -a -t -n -p99 -i100 -d50
      policy: fifo: loadavg: 0.00 0.13 0.31 2/139 28798
      
      T: 0 (28791) P:99 I:100 C:  25072 Min:      4 Act:    5 Avg:    6 Max:     122
      T: 1 (28792) P:98 I:150 C:  16715 Min:      4 Act:    6 Avg:    5 Max:      27
      T: 2 (28793) P:97 I:200 C:  12534 Min:      4 Act:    5 Avg:    4 Max:       8
      T: 3 (28794) P:96 I:250 C:  10028 Min:      4 Act:    5 Avg:    5 Max:      96
      T: 4 (28795) P:95 I:300 C:   8357 Min:      5 Act:    6 Avg:    5 Max:      12
      T: 5 (28796) P:94 I:350 C:   7163 Min:      5 Act:    6 Avg:    5 Max:      12
      T: 6 (28797) P:93 I:400 C:   6267 Min:      4 Act:    5 Avg:    5 Max:       9
      T: 7 (28798) P:92 I:450 C:   5571 Min:      4 Act:    5 Avg:    5 Max:       9
      ^C[ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.108 MB perf.data (~4719 samples) ]
      
      [root@emilia ~]#
      
      This will create one extra thread per CPU:
      
      [root@emilia ~]# tuna -t cyclictest -CP
                            thread       ctxt_switches
          pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       28825   OTHER     0     0xff      2169          671      cyclictest
        28832   FIFO    93        6     52338            1      cyclictest
        28833   FIFO    92        7     46524            1      cyclictest
        28826   FIFO    99        0    209360            1      cyclictest
        28827   FIFO    98        1    139577            1      cyclictest
        28828   FIFO    97        2    104686            0      cyclictest
        28829   FIFO    96        3     83751            1      cyclictest
        28830   FIFO    95        4     69794            1      cyclictest
        28831   FIFO    94        5     59825            1      cyclictest
      [root@emilia ~]#
      
      So we should expect only samples for the above 9 threads when using the
      --dump-raw-trace|-D perf report switch to look at the column with the tid:
      
      [root@emilia ~]# perf report -D | grep RECORD_SAMPLE | cut -d/ -f2 | cut -d: -f1 | sort | uniq -c
          629 28825
          110 28826
          491 28827
          308 28828
          198 28829
          621 28830
          225 28831
          203 28832
           89 28833
      [root@emilia ~]#
      
      So for workloads started by 'perf record' seems to work, now for existing workloads,
      just run cyclictest first, without 'perf record':
      
      [root@emilia ~]# tuna -t cyclictest -CP
                            thread       ctxt_switches
          pid SCHED_ rtpri affinity voluntary nonvoluntary             cmd
       28859   OTHER     0     0xff       594          200      cyclictest
        28864   FIFO    95        4     16587            1      cyclictest
        28865   FIFO    94        5     14219            1      cyclictest
        28866   FIFO    93        6     12443            0      cyclictest
        28867   FIFO    92        7     11062            1      cyclictest
        28860   FIFO    99        0     49779            1      cyclictest
        28861   FIFO    98        1     33190            1      cyclictest
        28862   FIFO    97        2     24895            1      cyclictest
        28863   FIFO    96        3     19918            1      cyclictest
      [root@emilia ~]#
      
      and then later did:
      
      [root@emilia ~]# perf record --pid 28859 sleep 3
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.027 MB perf.data (~1195 samples) ]
      [root@emilia ~]#
      
      To collect 3 seconds worth of samples for pid 28859 and its children:
      
      [root@emilia ~]# perf report -D | grep RECORD_SAMPLE | cut -d/ -f2 | cut -d: -f1 | sort | uniq -c
           15 28859
           33 28860
           19 28861
           13 28862
           13 28863
           10 28864
           11 28865
            9 28866
          255 28867
      [root@emilia ~]#
      
      Works, last thing is to check if looking at just one of those threads also works:
      
      [root@emilia ~]# perf record --tid 28866 sleep 3
      [ perf record: Woken up 1 times to write data ]
      [ perf record: Captured and wrote 0.006 MB perf.data (~242 samples) ]
      [root@emilia ~]# perf report -D | grep RECORD_SAMPLE | cut -d/ -f2 | cut -d: -f1 | sort | uniq -c
            3 28866
      [root@emilia ~]#
      
      Works too.
      Reported-by: NJeff Moyer <jmoyer@redhat.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      401b8e13
  15. 31 1月, 2011 1 次提交
    • A
      perf evlist: Store pointer to the cpu and thread maps · 7e2ed097
      Arnaldo Carvalho de Melo 提交于
      So that we don't have to pass it around to the several methods that
      needs it, simplifying usage.
      
      There is one case where we don't have the thread/cpu map in advance,
      which is in the parsing routines used by top, stat, record, that we have
      to wait till all options are parsed to know if a cpu or thread list was
      passed to then create those maps.
      
      For that case consolidate the cpu and thread map creation via
      perf_evlist__create_maps() out of the code in top and record, while also
      providing a perf_evlist__set_maps() for cases where multiple evlists
      share maps or for when maps that represent CPU sockets, for instance,
      get crafted out of topology information or subsets of threads in a
      particular application are to be monitored, providing more granularity
      in specifying which cpus and threads to monitor.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7e2ed097
  16. 30 1月, 2011 3 次提交
  17. 24 1月, 2011 2 次提交
    • A
      perf threads: Move thread_map to separate file · fd78260b
      Arnaldo Carvalho de Melo 提交于
      To untangle it from struct thread handling, that is tied to symbols, etc.
      
      Right now in the python bindings I'm working on I need just a subset of
      the util/ files, untangling it allows me to do that.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fd78260b
    • F
      perf record: auto detect when stdout is a pipe · d7065adb
      Franck Bui-Huu 提交于
      This patch gives the ability to 'perf record' to detect when its stdout
      has been redirected to a pipe. There's now no more need to add '-o -'
      switch in this case.
      
      However '-o <path>' option has always precedence, that is if specified
      and stdout has been connected via a pipe then the output will go into
      the specified output.
      
      LKML-Reference: <m3ipxo966i.fsf@gmail.com>
      Signed-off-by: NFranck Bui-Huu <fbuihuu@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d7065adb
  18. 23 1月, 2011 7 次提交
    • A
      perf record: Use perf_evlist__mmap · 0a27d7f9
      Arnaldo Carvalho de Melo 提交于
      There is more stuff that can go to the perf_ev{sel,list} layer, like
      detecting if sample_id_all is available, etc, but lets try using this in
      'perf test' first.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0a27d7f9
    • A
      perf record: Move perf_mmap__write_tail to perf.h · 115d2d89
      Arnaldo Carvalho de Melo 提交于
      Close to perf_mmap__read_head() and the perf_mmap struct definition.
      This is useful for any recorder, and we will need it in 'perf test'.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      115d2d89
    • A
      perf record: Use struct perf_mmap and helpers · 744bd8aa
      Arnaldo Carvalho de Melo 提交于
      Paving the way to using perf_evsel->mmap, do this to reduce the patch
      noise in the next ones.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      744bd8aa
    • A
      perf record: Use perf_evsel__open · dd7927f4
      Arnaldo Carvalho de Melo 提交于
      Now its time to factor out the mmap handling bits into the perf_evsel
      class.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      dd7927f4
    • A
      perf evlist: Adopt the pollfd array · 5c581041
      Arnaldo Carvalho de Melo 提交于
      Allocating just the space needed for nr_cpus * nr_threads * nr_evsels,
      not the MAX_NR_CPUS and counters.
      
      LKML-Reference: <new-submission>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5c581041
    • A
      perf evsel: Introduce perf_evlist · 361c99a6
      Arnaldo Carvalho de Melo 提交于
      Killing two more perf wide global variables: nr_counters and evsel_list
      as a list_head.
      
      There are more operations that will need more fields in perf_evlist,
      like the pollfd for polling all the fds in a list of evsel instances.
      
      Use option->value to pass the evsel_list to parse_{events,filters}.
      
      LKML-Reference: <new-submission>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      361c99a6
    • A
      perf tools: Fix 64 bit integer format strings · 9486aa38
      Arnaldo Carvalho de Melo 提交于
      Using %L[uxd] has issues in some architectures, like on ppc64.  Fix it
      by making our 64 bit integers typedefs of stdint.h types and using
      PRI[ux]64 like, for instance, git does.
      
      Reported by Denis Kirjanov that provided a patch for one case, I went
      and changed all cases.
      Reported-by: NDenis Kirjanov <dkirjanov@kernel.org>
      Tested-by: NDenis Kirjanov <dkirjanov@kernel.org>
      LKML-Reference: <20110120093246.GA8031@hera.kernel.org>
      Cc: Denis Kirjanov <dkirjanov@kernel.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Pingtian Han <phan@redhat.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9486aa38
  19. 18 1月, 2011 1 次提交
    • A
      perf tools: Fix tracepoint id to string perf.data header table · ad7f4e3f
      Arnaldo Carvalho de Melo 提交于
      It was broken by f006d25a that passed just the event name, not the complete
      sys:event that it expected to open the /sys/.../sys/sys:event/id file to get
      the id.
      
      Fix it by moving it to after parse_events in cmd_record, as at that point
      we can just traverse the evsel_list and use evsel->attr.config +
      event_name(evsel) instead of re-opening the /id file.
      Reported-by: NFranck Bui-Huu <vagabon.xyz@gmail.com>
      Cc: Franck Bui-Huu <vagabon.xyz@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Han Pingtian <phan@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <20110117202801.GG2085@ghostprotocols.net>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ad7f4e3f
  20. 13 1月, 2011 1 次提交
    • K
      perf record: Add "nodelay" mode, disabled by default · acac03fa
      Kirill Smelkov 提交于
      Sometimes there is a need to use perf in "live-log" mode. The problem
      is, for seldom events, actual info output is largely delayed because
      perf-record reads sample data in whole pages.
      
      So for such scenarious, add flag for perf-record to go in "nodelay"
      mode. To track e.g. what's going on in icmp_rcv while ping is running
      Use it with something like this:
      
      (1) $ perf probe -L icmp_rcv | grep -U8 '^ *43\>'
                                          goto error;
                          }
               38         if (!pskb_pull(skb, sizeof(*icmph)))
                                  goto error;
                          icmph = icmp_hdr(skb);
      
               43         ICMPMSGIN_INC_STATS_BH(net, icmph->type);
                          /*
                           *      18 is the highest 'known' ICMP type. Anything else is a mystery
                           *
                           *      RFC 1122: 3.2.2  Unknown ICMP messages types MUST be silently
                           *                discarded.
                           */
               50         if (icmph->type > NR_ICMP_TYPES)
                                  goto error;
      
          $ perf probe icmp_rcv:43 'type=icmph->type'
      
      (2) $ cat trace-icmp.py
          [...]
          def trace_begin():
                  print "in trace_begin"
      
          def trace_end():
                  print "in trace_end"
      
          def probe__icmp_rcv(event_name, context, common_cpu,
                  common_secs, common_nsecs, common_pid, common_comm,
                  __probe_ip, type):
                          print_header(event_name, common_cpu, common_secs, common_nsecs,
                                  common_pid, common_comm)
      
                          print "__probe_ip=%u, type=%u\n" % \
                          (__probe_ip, type),
          [...]
      
      (3) $ perf record -a -D -e probe:icmp_rcv -o - | \
            perf script -i - -s trace-icmp.py
      
      Thanks to Peter Zijlstra for pointing how to do it.
      
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>, Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <20110112140613.GA11698@tugrik.mns.mnsspb.ru>
      Signed-off-by: NKirill Smelkov <kirr@mns.spb.ru>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      acac03fa
  21. 12 1月, 2011 1 次提交
  22. 11 1月, 2011 1 次提交
    • A
      perf evsel: Fix order of event list deletion · bd3bfe9e
      Arnaldo Carvalho de Melo 提交于
      We need to defer calling perf_evsel_list__delete() till after atexit
      registered routines, because we need to traverse the events being
      recorded at that time at least on 'perf record'.
      
      This fixes the problem reported by Thomas Renninger where cmd_record
      called by cmd_timechart would not write the tracing data to the perf.data
      file header because the evsel_list at atexit (control+C on 'perf timechart
      record') time would be empty, being already deleted by run_builtin(),
      and thus 'perf timechart' when trying to process such perf.data file would
      die with:
      
      "no trace data in the file"
      
      Problem introduced in 70d544d0.
      Reported-by: NThomas Renninger <trenn@suse.de>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Renninger <trenn@suse.de>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bd3bfe9e
  23. 10 1月, 2011 1 次提交
  24. 04 1月, 2011 4 次提交
    • A
      perf tools: Refactor all_tids to hold nr and the map · 5c98d466
      Arnaldo Carvalho de Melo 提交于
      So that later, we can pass the thread_map instance instead of
      (thread_num, thread_map) for things like perf_evsel__open and friends,
      just like was done with cpu_map.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5c98d466
    • A
      perf tools: Refactor cpumap to hold nr and the map · 60d567e2
      Arnaldo Carvalho de Melo 提交于
      So that later, we can pass the cpu_map instance instead of (nr_cpus, cpu_map)
      for things like perf_evsel__open and friends.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      60d567e2
    • A
      perf evsel: Delete the event selectors at exit · 70d544d0
      Arnaldo Carvalho de Melo 提交于
      Freeing all the possibly allocated resources, reducing complexity
      on each tool exit path.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      70d544d0
    • A
      perf tools: Introduce event selectors · 69aad6f1
      Arnaldo Carvalho de Melo 提交于
      Out of ad-hoc code and global arrays with hard coded sizes.
      
      This is the first step on having a library that will be first
      used on regression tests in the 'perf test' tool.
      
      [acme@felicio linux]$ size /tmp/perf.before
         text	   data	    bss	    dec	    hex	filename
      1273776	  97384	5104416	6475576	 62cf38	/tmp/perf.before
      [acme@felicio linux]$ size /tmp/perf.new
         text	   data	    bss	    dec	    hex	filename
      1275422	  97416	1392416	2765254	 2a31c6	/tmp/perf.new
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      69aad6f1
  25. 25 12月, 2010 1 次提交
    • A
      perf record: Fix use of sample_id_all userspace with !sample_id_all kernels · a43d3f08
      Arnaldo Carvalho de Melo 提交于
      Check if parse_single_tracepoint_event has already asked for PERF_SAMPLE_TIME.
      
      This is kludgy but short term fix for problems introduced by eac23d1c that
      broke 'perf script' by having different sample_types when using multiple
      tracepoint events when we use a perf binary that tries to use sample_id_all on
      an older kernel.
      
      We need to move counter creation to perf_session, support different
      sample_types, etc.
      
      Ongoing work on the perf test infrastructure needs this so that we can create
      counters to monitor threads generating specific events, etc.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Torok Edwin <edwintorok@gmail.com>
      Cc: Ian Munsie <imunsie@au1.ibm.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a43d3f08
  26. 22 12月, 2010 2 次提交
    • I
      perf record,report,annotate,diff: Process events in order · eac23d1c
      Ian Munsie 提交于
      This patch changes perf report to ask for the ID info on all events be
      default if recording from multiple CPUs.
      
      Perf report, annotate and diff will now process the events in order if
      the kernel is able to provide timestamps on all events. This ensures
      that events such as COMM and MMAP which are necessary to correctly
      interpret samples are processed prior to those samples so that they are
      attributed correctly.
      
      Before:
       # perf record ./cachetest
       # perf report
      
       # Events: 6K cycles
       #
       # Overhead  Command      Shared Object                           Symbol
       # ........  .......  .................  ...............................
       #
           74.11%    :3259  [unknown]          [k] 0x4a6c
            1.50%  cachetest  ld-2.11.2.so       [.] 0x1777c
            1.46%    :3259  [kernel.kallsyms]  [k] .perf_event_mmap_ctx
            1.25%    :3259  [kernel.kallsyms]  [k] restore
            0.74%    :3259  [kernel.kallsyms]  [k] ._raw_spin_lock
            0.71%    :3259  [kernel.kallsyms]  [k] .filemap_fault
            0.66%    :3259  [kernel.kallsyms]  [k] .memset
            0.54%  cachetest  [kernel.kallsyms]  [k] .sha_transform
            0.54%    :3259  [kernel.kallsyms]  [k] .copy_4K_page
            0.54%    :3259  [kernel.kallsyms]  [k] .find_get_page
            0.52%    :3259  [kernel.kallsyms]  [k] .trace_hardirqs_off
            0.50%    :3259  [kernel.kallsyms]  [k] .__do_fault
      <SNIP>
      
      After:
       # perf report
      
       # Events: 6K cycles
       #
       # Overhead  Command      Shared Object                           Symbol
       # ........  .......  .................  ...............................
       #
           44.28%  cachetest  cachetest          [.] sumArrayNaive
           22.53%  cachetest  cachetest          [.] sumArrayOptimal
            6.59%  cachetest  ld-2.11.2.so       [.] 0x1777c
            2.13%  cachetest  [unknown]          [k] 0x340
            1.46%  cachetest  [kernel.kallsyms]  [k] .perf_event_mmap_ctx
            1.25%  cachetest  [kernel.kallsyms]  [k] restore
            0.74%  cachetest  [kernel.kallsyms]  [k] ._raw_spin_lock
            0.71%  cachetest  [kernel.kallsyms]  [k] .filemap_fault
            0.66%  cachetest  [kernel.kallsyms]  [k] .memset
            0.54%  cachetest  [kernel.kallsyms]  [k] .copy_4K_page
            0.54%  cachetest  [kernel.kallsyms]  [k] .find_get_page
            0.54%  cachetest  [kernel.kallsyms]  [k] .sha_transform
            0.52%  cachetest  [kernel.kallsyms]  [k] .trace_hardirqs_off
            0.50%  cachetest  [kernel.kallsyms]  [k] .__do_fault
      <SNIP>
      
      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: Thomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <1291872833-839-1-git-send-email-imunsie@au1.ibm.com>
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      eac23d1c
    • I
      perf session: Fallback to unordered processing if no sample_id_all · 21ef97f0
      Ian Munsie 提交于
      If we are running the new perf on an old kernel without support for
      sample_id_all, we should fall back to the old unordered processing of
      events. If we didn't than we would *always* process events without
      timestamps out of order, whether or not we hit a reordering race. In
      other words, instead of there being a chance of not attributing samples
      correctly, we would guarantee that samples would not be attributed.
      
      While processing all events without timestamps before events with
      timestamps may seem like an intuitive solution, it falls down as
      PERF_RECORD_EXIT events would also be processed before any samples.
      Even with a workaround for that case, samples before/after an exec would
      not be attributed correctly.
      
      This patch allows commands to indicate whether they need to fall back to
      unordered processing, so that commands that do not care about timestamps
      on every event will not be affected. If we do fallback, this will print
      out a warning if report -D was invoked.
      
      This patch adds the test in perf_session__new so that we only need to
      test once per session. Commands that do not use an event_ops (such as
      record and top) can simply pass NULL in it's place.
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      LKML-Reference: <1291951882-sup-6069@au1.ibm.com>
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      21ef97f0