1. 18 12月, 2015 7 次提交
  2. 11 12月, 2015 1 次提交
    • M
      perf tools: Make perf_session__register_idle_thread drop the refcount · 9d8b172f
      Masami Hiramatsu 提交于
      Note that since the thread was already inserted to the session
      list, it will be released when the session is released.
      Also, in perf_session__register_idle_thread() failure path,
      the thread should be put before returning.
      
      Refcnt debugger shows that the perf_session__register_idle_thread
      gets the returned thread, but the caller (__cmd_top) does not
      put the returned idle thread.
      
        ----
        ==== [0] ====
        Unreclaimed thread@0x24e6240
        Refcount +1 => 0 at
          ./perf(thread__new+0xe5) [0x4c8a75]
          ./perf(machine__findnew_thread+0x9a) [0x4bbdba]
          ./perf(perf_session__register_idle_thread+0x28) [0x4c63c8]
          ./perf(cmd_top+0xd7d) [0x43cf6d]
          ./perf() [0x47ba35]
          ./perf(main+0x617) [0x4225b7]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f06027c5af5]
          ./perf() [0x42272d]
        Refcount +1 => 1 at
          ./perf(thread__get+0x2c) [0x4c8bcc]
          ./perf(machine__findnew_thread+0xee) [0x4bbe0e]
          ./perf(perf_session__register_idle_thread+0x28) [0x4c63c8]
          ./perf(cmd_top+0xd7d) [0x43cf6d]
          ./perf() [0x47ba35]
          ./perf(main+0x617) [0x4225b7]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f06027c5af5]
          ./perf() [0x42272d]
        Refcount +1 => 2 at
          ./perf(thread__get+0x2c) [0x4c8bcc]
          ./perf(machine__findnew_thread+0x112) [0x4bbe32]
          ./perf(perf_session__register_idle_thread+0x28) [0x4c63c8]
          ./perf(cmd_top+0xd7d) [0x43cf6d]
          ./perf() [0x47ba35]
          ./perf(main+0x617) [0x4225b7]
          /lib64/libc.so.6(__libc_start_main+0xf5) [0x7f06027c5af5]
          ./perf() [0x42272d]
        ----
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20151209021122.10245.69707.stgit@localhost.localdomain
      [ Drop the refcount in perf_session__register_idle_thread() ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9d8b172f
  3. 12 11月, 2015 1 次提交
  4. 01 10月, 2015 1 次提交
  5. 29 9月, 2015 2 次提交
  6. 18 9月, 2015 1 次提交
    • M
      perf record: Avoid infinite loop at buildid processing with no samples · 381c02f6
      Mark Rutland 提交于
      If a session contains no events, we can get stuck in an infinite loop in
      __perf_session__process_events, with a non-zero file_size and data_offset, but
      a zero data_size.
      
      In this case, we can mmap the entirety of the file (consisting of the file and
      attribute headers), and fetch_mmaped_event will correctly refuse to read any
      (unmapped and non-existent) event headers. This causes
      __perf_session__process_events to unmap the file and retry with the exact same
      parameters, getting stuck in an infinite loop.
      
      This has been observed to result in an exit-time hang when counting
      rare/unschedulable events with perf record, and can be triggered artificially
      with the script below:
      
        ----
        #!/bin/sh
        printf "REPRO: launching perf\n";
        ./perf record -e software/config=9/ sleep 1 &
        PERF_PID=$!;
        sleep 0.002;
        kill -2 $PERF_PID;
        printf "REPRO: waiting for perf (%d) to exit...\n" "$PERF_PID";
        wait $PERF_PID;
        printf "REPRO: perf exited\n";
        ----
      
      To avoid this, have __perf_session__process_events bail out early when
      the file has no data (i.e. it has no events).
      
      Commiter note:
      
      I only managed to reproduce this when setting
      /proc/sys/kernel/kptr_restrict to '1' and changing the code to
      purposefully not process any samples and no synthesized samples, i.e.
      kptr_restrict prevents 'record' from synthesizing the kernel mmaps for
      vmlinux + modules and since it is a workload started from perf, we don't
      synthesize mmap/comm records for existing threads.
      
      Adrian Hunter managed to reproduce it in his environment tho.
      Signed-off-by: NMark Rutland <mark.rutland@arm.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@kernel.org>
      Tested-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1442423929-12253-1-git-send-email-mark.rutland@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      381c02f6
  7. 14 9月, 2015 2 次提交
  8. 04 9月, 2015 1 次提交
  9. 03 9月, 2015 1 次提交
    • K
      perf tools: Store the cpu socket and core ids in the perf.data header · 2bb00d2f
      Kan Liang 提交于
      This patch stores the cpu socket_id and core_id in a perf.data header,
      and reads them into the perf_env struct when processing perf.data files.
      
      The changes modifies the CPU_TOPOLOGY section, making sure it is
      backward/forward compatible.
      
      The patch checks the section size before reading the core and socket ids.
      
      It never reads data crossing the section boundary.  An old perf binary
      without this patch can also correctly read the perf.data from a new perf
      with this patch.
      
      Because the new info is added at the end of the cpu_topology section, an
      old perf tool ignores the extra data.
      
      Examples:
      
      1. New perf with this patch read perf.data from an old perf without the
         patch:
      
        $ perf_new report -i perf_old.data --header-only -I
        ......
        # sibling threads : 33
        # sibling threads : 34
        # sibling threads : 35
        # Core ID and Socket ID information is not available
        # node0 meminfo  : total = 32823872 kB, free = 29315548 kB
        # node0 cpu list : 0-17,36-53
        ......
      
      2. Old perf without the patch reads perf.data from a new perf with the
         patch:
      
        $ perf_old report -i perf_new.data --header-only -I
        ......
        # sibling threads : 33
        # sibling threads : 34
        # sibling threads : 35
        # node0 meminfo  : total = 32823872 kB, free = 29190932 kB
        # node0 cpu list : 0-17,36-53
        ......
      
      3. New perf read new perf.data:
      
        $ perf_new report -i perf_new.data --header-only -I
        ......
        # sibling threads : 33
        # sibling threads : 34
        # sibling threads : 35
        # CPU 0: Core ID 0, Socket ID 0
        # CPU 1: Core ID 1, Socket ID 0
        ......
        # CPU 61: Core ID 10, Socket ID 1
        # CPU 62: Core ID 11, Socket ID 1
        # CPU 63: Core ID 16, Socket ID 1
        # node0 meminfo  : total = 32823872 kB, free = 29190932 kB
        # node0 cpu list : 0-17,36-53
      Signed-off-by: NKan Liang <kan.liang@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Link: http://lkml.kernel.org/r/1441115893-22006-2-git-send-email-kan.liang@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2bb00d2f
  10. 29 8月, 2015 1 次提交
  11. 07 8月, 2015 1 次提交
  12. 29 7月, 2015 1 次提交
    • A
      perf session env: Rename exit method · 4c7de49a
      Arnaldo Carvalho de Melo 提交于
      The semantic associated in tools/perf/ with foo__delete(instance) is to
      release all resources referenced by 'instance' members and then release
      the memory for 'instance' itself.
      
      The perf_session_env__delete() function isn't doing this, it just does
      the first part, but the space used by 'instance' itself isn't freed, as
      it is embedded in a larger structure, that will be freed at other stage.
      
      For these cases we se foo__exit(), i.e. the usage is:
      
       void foo__delete(foo)
       {
               if (foo) {
                       foo__exit(foo);
                       free(foo);
               }
       }
      
      But when we have something like:
      
       struct bar {
               struct foo foo;
               . . .
       }
      
      Then we can't really call foo__delete(&bar.foo), we must have this
      instead:
      
       void bar__exit(bar)
       {
               foo__exit(&bar.foo);
               /* free other bar-> resources */
       }
      
       void bar__delete(bar)
       {
               if (bar) {
      		bar__exit(bar);
                      free(bar);
               }
       }
      
      So just rename perf_session_env__delete() to perf_session_env__exit().
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-djbgpcfo5udqptx3q0flwtmk@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4c7de49a
  13. 24 7月, 2015 1 次提交
  14. 22 7月, 2015 1 次提交
  15. 26 6月, 2015 1 次提交
  16. 24 6月, 2015 2 次提交
  17. 20 6月, 2015 3 次提交
  18. 18 6月, 2015 1 次提交
    • W
      perf tools: Fix a problem when opening old perf.data with different byte order · b30b6172
      Wang Nan 提交于
      Following error occurs when trying to use 'perf report' on x86_64 to
      cross analysis a perf.data generated by an old perf on a big-endian
      machine:
      
       # perf report
       *** Error in `/home/w00229757/perf': free(): invalid next size (fast): 0x00000000032c99f0 ***
       ======= Backtrace: =========
       /lib64/libc.so.6(+0x6eeef)[0x7ff6ff7e2eef]
       /lib64/libc.so.6(+0x78cae)[0x7ff6ff7eccae]
       /lib64/libc.so.6(+0x79987)[0x7ff6ff7ed987]
       /path/to/perf[0x4ac734]
       /path/to/perf[0x4ac829]
       /path/to/perf(perf_header__process_sections+0x129)[0x4ad2c9]
       /path/to/perf(perf_session__read_header+0x2e1)[0x4ad9e1]
       /path/to/perf(perf_session__new+0x168)[0x4bd458]
       /path/to/perf(cmd_report+0xfa0)[0x43eb70]
       /path/to/perf[0x47adc3]
       /path/to/perf(main+0x5f6)[0x42fd06]
       /lib64/libc.so.6(__libc_start_main+0xf5)[0x7ff6ff795bd5]
       /path/to/perf[0x42fe35]
       ======= Memory map: ========
       [SNIP]
      
      The bug is in perf_event__attr_swap(). It swaps all fields in 'struct
      perf_event_attr' without checking whether the swapped field exist or
      not. In addition, in read_event_desc() allocs memory for attr according
      to size read from perf.data.
      
      Therefore, if the perf.data is collected by an old perf (without
      aux_watermark, for example), when perf_event__attr_swap() swaping
      attr->aux_watermark it destroy malloc's metadata.
      
      This patch introduces boundary checking in perf_event__attr_swap(). It
      adds macros bswap_field_64 and bswap_field_32 into
      perf_event__attr_swap() to make it only swap exist fields.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1434534999-85347-1-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b30b6172
  19. 11 6月, 2015 1 次提交
    • H
      perf tools: Fix build failure on 32-bit arch · 6ba29c2f
      He Kuang 提交于
      Failed in 32bit arch build like this:
      
          CC       /opt/h00206996/output/perf/arm32/builtin-record.o
        util/session.c: In function ‘perf_session__warn_about_errors’:
        util/session.c:1304:9: error: format ‘%lu’ expects argument of type ‘long unsigned int’,
                               but argument 2 has type ‘long long unsigned int’ [-Werror=format=]
      
        builtin-report.c: In function ‘perf_evlist__tty_browse_hists’:
        builtin-report.c:323:2: error: format ‘%lu’ expects argument of type ‘long unsigned int’,
                                but argument 3 has type ‘u64’ [-Werror=format=]
      
      Replace %lu format strings in warning message with PRIu64 for u64
      'total_lost_samples' to fix this problem.
      Signed-off-by: NHe Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1434026664-71642-1-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6ba29c2f
  20. 07 6月, 2015 1 次提交
    • K
      perf tools: handle PERF_RECORD_LOST_SAMPLES · c4937a91
      Kan Liang 提交于
      This patch modifies the perf tool to handle the new RECORD type,
      PERF_RECORD_LOST_SAMPLES.
      
      The number of lost-sample events is stored in
      .nr_events[PERF_RECORD_LOST_SAMPLES]. The exact number of samples
      which the kernel dropped is stored in total_lost_samples.
      
      When the percentage of dropped samples is greater than 5%, a warning
      is printed.
      
      Here are some examples:
      
      Eg 1, Recording different frequently-occurring events is safe with the
            patch. Only a very low drop rate is associated with such actions.
      
      $ perf record -e '{cycles:p,instructions:p}' -c 20003 --no-time ~/tchain ~/tchain
      
      $ perf report -D | tail
                SAMPLE events:     120243
                 MMAP2 events:          5
          LOST_SAMPLES events:         24
        FINISHED_ROUND events:         15
      cycles:p stats:
                 TOTAL events:      59348
                SAMPLE events:      59348
      instructions:p stats:
                 TOTAL events:      60895
                SAMPLE events:      60895
      
      $ perf report --stdio --group
       # To display the perf.data header info, please use --header/--header-only options.
       #
       #
       # Total Lost Samples: 24
       #
       # Samples: 120K of event 'anon group { cycles:p, instructions:p }'
       # Event count (approx.): 24048600000
       #
       #         Overhead  Command      Shared Object     Symbol
       # ................  ...........  ................
       ..................................
       #
          99.74%  99.86%  tchain_edit  tchain_edit       [.] f3
           0.09%   0.02%  tchain_edit  tchain_edit       [.] f2
           0.04%   0.00%  tchain_edit  [kernel.vmlinux]  [k] ixgbe_read_reg
      
      Eg 2, Recording the same thing multiple times can lead to high drop
            rate, but it is not a useful configuration.
      
      $ perf record -e '{cycles:p,cycles:p}' -c 20003 --no-time ~/tchain
      Warning: Processed 600592 samples and lost 99.73% samples!
      [perf record: Woken up 148 times to write data]
      [perf record: Captured and wrote 36.922 MB perf.data (1206322 samples)]
      [perf record: Woken up 1 times to write data]
      [perf record: Captured and wrote 0.121 MB perf.data (1629 samples)]
      Signed-off-by: NKan Liang <kan.liang@intel.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: acme@infradead.org
      Cc: eranian@google.com
      Link: http://lkml.kernel.org/r/1431285195-14269-9-git-send-email-kan.liang@intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c4937a91
  21. 27 5月, 2015 1 次提交
    • A
      perf session: Fix perf_session__peek_event() · 554e92ed
      Adrian Hunter 提交于
      perf_session__peek_event() generally leverages there being a single mmap
      of the perf.data file, however on 32-bit platforms when there is more
      that 32MiB of data, then there are multiple mmaps, so
      perf_session__peek_event() reads from the file.
      
      In that case a couple of bugs were exposed (note how the seg. fault
      appears with >32M of data):
      
         $ perf record --per-thread -e intel_bts// ../rtit-tests/loopy 1000000
         [ perf record: Woken up 13 times to write data ]
         [ perf record: Captured and wrote 24.568 MB perf.data ]
         $ perf script > /dev/null
         $ perf record --per-thread -e intel_bts// ../rtit-tests/loopy 10000000
         [ perf record: Woken up 136 times to write data ]
         [ perf record: Captured and wrote 270.794 MB perf.data ]
         $ perf script > /dev/null
         Segmentation fault (core dumped)
      
      The wrong address was being passed to the readn() function and the
      buffer size was not being checked.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Link: http://lkml.kernel.org/r/1432040746-1755-5-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      554e92ed
  22. 06 5月, 2015 2 次提交
  23. 05 5月, 2015 1 次提交
    • A
      perf tools: Add AUX area tracing index · 99fa2984
      Adrian Hunter 提交于
      Add an index of AUX area tracing events within a perf.data file.
      
      perf record uses a special user event PERF_RECORD_FINISHED_ROUND to
      enable sorting of events in chunks instead of having to sort all events
      altogether.
      
      AUX area tracing events contain data that can span back to the very
      beginning of the recording period. i.e. they do not obey the rules of
      PERF_RECORD_FINISHED_ROUND.
      
      By adding an index, AUX area tracing events can be found in advance and
      the PERF_RECORD_FINISHED_ROUND approach works as usual.
      
      The index is recorded with the auxtrace feature in the perf.data file.
      A session reads the index but does not process it.  An AUX area decoder
      can queue all the AUX area data in advance using
      auxtrace_queues__process_index() or otherwise process the index in some
      custom manner.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/1430404667-10593-3-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      99fa2984
  24. 29 4月, 2015 5 次提交