1. 12 8月, 2012 1 次提交
    • J
      perf tools: Support for DWARF CFI unwinding on post processing · 71ad0f5e
      Jiri Olsa 提交于
      This brings the support for DWARF cfi unwinding on perf post
      processing. Call frame informations are retrieved and then passed
      to libunwind that requests memory and register content from the
      applications.
      
      Adding unwind object to handle the user stack backtrace based
      on the user register values and user stack dump.
      
      The unwind object access the libunwind via remote interface
      and provides to it all the necessary data to unwind the stack.
      
      The unwind interface provides following function:
      	unwind__get_entries
      
      And callback (specified in above function) to retrieve
      the backtrace entries:
      	typedef int (*unwind_entry_cb_t)(struct unwind_entry *entry,
      					 void *arg);
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Original-patch-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: "Frank Ch. Eigler" <fche@redhat.com>
      Cc: Arun Sharma <asharma@fb.com>
      Cc: Benjamin Redelings <benjamin.redelings@nescent.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Ulrich Drepper <drepper@gmail.com>
      Link: http://lkml.kernel.org/r/1344345647-11536-12-git-send-email-jolsa@redhat.com
      [ Replaced use of perf_session by usage of perf_evsel ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      71ad0f5e
  2. 11 8月, 2012 1 次提交
    • J
      perf tools: Support user regs and stack in sample parsing · 0f6a3015
      Jiri Olsa 提交于
      Adding following info to be parsed out of the event sample:
       - user register set
       - user stack dump
      
      Both are global and specific to all events within the session.
      This info will be used in the unwind patches coming in shortly.
      
      Adding simple output printout (report -D) for both register and
      stack dumps.
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Original-patch-by: NFrederic Weisbecker <fweisbec@gmail.com>
      Cc: "Frank Ch. Eigler" <fche@redhat.com>
      Cc: Arun Sharma <asharma@fb.com>
      Cc: Benjamin Redelings <benjamin.redelings@nescent.org>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: Cyrill Gorcunov <gorcunov@openvz.org>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Robert Richter <robert.richter@amd.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Ulrich Drepper <drepper@gmail.com>
      Link: http://lkml.kernel.org/r/1344345647-11536-11-git-send-email-jolsa@redhat.com
      [ Use evsel->attr.sample_regs_user ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0f6a3015
  3. 03 8月, 2012 1 次提交
  4. 02 8月, 2012 5 次提交
  5. 25 7月, 2012 2 次提交
    • D
      perf kvm: Fix bug resolving guest kernel syms · adb5d2a4
      David Ahern 提交于
      Guest kernel symbols are not resolved despite passing the information
      needed to resolve them. e.g.,
      
      perf kvm --guest --guestmount=/tmp/guest-mount record -a -- sleep 1
      perf kvm --guest --guestmount=/tmp/guest-mount report --stdio
      
          36.55%  [guest/11399]  [unknown]         [g] 0xffffffff81600bc8
          33.19%  [guest/10474]  [unknown]         [g] 0x00000000c0116e00
          30.26%  [guest/11094]  [unknown]         [g] 0xffffffff8100a288
          43.69%  [guest/10474]  [unknown]         [g] 0x00000000c0103d90
          37.38%  [guest/11399]  [unknown]         [g] 0xffffffff81600bc8
          12.24%  [guest/11094]  [unknown]         [g] 0xffffffff810aa91d
           6.69%  [guest/11094]  [unknown]         [u] 0x00007fa784d721c3
      
      which is just pathetic.
      
      After a maddening 2 days sifting through perf minutia I found it --
      id_hdr_size is not initialized for guest machines. This shows up on the
      report side as random garbage for the cpu and timestamp, e.g.,
      
      29816 7310572949125804849 0x1ac0 [0x50]: PERF_RECORD_MMAP ...
      
      That messes up the sample sorting such that synthesized guest maps are
      processed last.
      
      With this patch you get a much more helpful report:
      
        12.11%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] irqtime_account_process_tick
        10.58%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] run_timer_softirq
         6.95%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] printk_needs_cpu
         6.50%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] do_timer
         6.45%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] idle_balance
         4.90%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] native_read_tsc
          ...
      
      v2:
      - changed rbtree walk to use rb_first per Namhyung's suggestion
      Tested-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1342826756-64663-5-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      adb5d2a4
    • D
      perf kvm: Guest userspace samples should not be lumped with host uspace · 7c0f4a41
      David Ahern 提交于
      e.g., perf kvm --host  --guest report -i perf.data --stdio -D
      shows:
      
      1 599127912065356 0x143b8 [0x48]: PERF_RECORD_SAMPLE(IP, 5): 5671/5676: 0x7fdf95a061c0 period: 1 addr: 0
      ... chain: nr:2
      .....  0: ffffffffffffff80
      .....  1: fffffffffffffe00
       ... thread: qemu-kvm:5671
       ...... dso: <not found>
      
      (IP, 5) means sample in guest userspace. Those samples should not be lumped
      into the VMM's host thread. i.e, the report output:
      
          56.86%  qemu-kvm  [unknown]         [u] 0x00007fdf95a061c0
      
      With this patch the output emphasizes it is a guest userspace hit:
      
          56.86%  [guest/5671]  [unknown]         [u] 0x00007fdf95a061c0
      
      Looking at 3 VMs (2 64-bit, 1 32-bit) with each running a CPU bound
      process (openssl speed), perf report currently shows:
      
        93.84%  117726   qemu-kvm  [unknown]   [u] 0x00007fd7dcaea8e5
      
      which is wrong. With this patch you get:
      
        31.50%   39258   [guest/18772]  [unknown]   [u] 0x00007fd7dcaea8e5
        31.50%   39236   [guest/11230]  [unknown]   [u] 0x0000000000a57340
        30.84%   39232   [guest/18395]  [unknown]   [u] 0x00007f66f641e107
      Tested-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1342826756-64663-4-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7c0f4a41
  6. 02 7月, 2012 1 次提交
    • D
      perf kvm: Fix regression with guest machine creation · 207b5792
      David Ahern 提交于
      Commit 743eb868 reworked when the
      machines were created. Prior to this commit guest machines could be
      created in perf_event__process_kernel_mmap() while processing kernel
      MMAP events. This commit assumes that the machines exist by the time
      perf_session_deliver_event is called (e.g., during processing of build
      id events) - which is not always correct.
      
      One example is the use of default guest args (--guestkallsyms and
      --guestmodules) for short times where no samples hit within a guest
      module. For this case no build id is added to the file header. No build
      id == no machine created. That leads to the next example -- the use of
      no-buildid (-B) on the record for all perf-kvm invocations. In both
      cases perf report dies with a SEGFAULT of the form:
      
      (gdb) bt
      0  0x000000000046dd7b in machine__mmap_name (self=0x0, bf=0x7fffffffbd20 "q\021", size=4096) at util/map.c:715
      1  0x0000000000444161 in perf_event__process_kernel_mmap (tool=0x7fffffffdd80, event=0x7ffff7fb4120, machine=0x0) at util/event.c:562
      2  0x0000000000444642 in perf_event__process_mmap (tool=0x7fffffffdd80, event=0x7ffff7fb4120, sample=0x7fffffffd210, machine=0x0)
          at util/event.c:668
      3  0x0000000000470e0b in perf_session_deliver_event (session=0x915ca0, event=0x7ffff7fb4120, sample=0x7fffffffd210, tool=0x7fffffffdd80,
          file_offset=8480) at util/session.c:979
      4  0x000000000047032e in flush_sample_queue (s=0x915ca0, tool=0x7fffffffdd80) at util/session.c:679
      5  0x0000000000471c8d in __perf_session__process_events (session=0x915ca0, data_offset=400, data_size=150448, file_size=150848, tool=
          0x7fffffffdd80) at util/session.c:1363
      6  0x0000000000471d42 in perf_session__process_events (self=0x915ca0, tool=0x7fffffffdd80) at util/session.c:1379
      7  0x000000000042484a in __cmd_report (rep=0x7fffffffdd80) at builtin-report.c:368
      8  0x0000000000425bf1 in cmd_report (argc=0, argv=0x915b00, prefix=0x0) at builtin-report.c:756
      9  0x0000000000438505 in __cmd_report (argc=4, argv=0x7fffffffe260) at builtin-kvm.c:84
      10 0x000000000043882a in cmd_kvm (argc=4, argv=0x7fffffffe260, prefix=0x0) at builtin-kvm.c:131
      11 0x00000000004152cd in run_builtin (p=0x7a54e8, argc=9, argv=0x7fffffffe260) at perf.c:273
      12 0x00000000004154c7 in handle_internal_command (argc=9, argv=0x7fffffffe260) at perf.c:345
      13 0x0000000000415613 in run_argv (argcp=0x7fffffffe14c, argv=0x7fffffffe140) at perf.c:389
      14 0x0000000000415899 in main (argc=9, argv=0x7fffffffe260) at perf.c:487
      
      Fix by allowing the machine to be created in perf_session_deliver_event.
      
      Tested with --guestmount option and default guest args, with and without
      -B arg on record for both and for short (10 seconds) and long (10
      minutes) windows.
      Reported-by: NPradeep Kumar Surisetty <psuriset@linux.vnet.ibm.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Pradeep Kumar Surisetty <psuriset@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/1341180697-64515-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      207b5792
  7. 28 6月, 2012 1 次提交
    • A
      perf tools: Stop using a global trace events description list · da378962
      Arnaldo Carvalho de Melo 提交于
      The pevent thing is per perf.data file, so I made it stop being static
      and become a perf_session member, so tools processing perf.data files
      use perf_session and _there_ we read the trace events description into
      session->pevent and then change everywhere to stop using that single
      global pevent variable and use the per session one.
      
      Note that it _doesn't_ fall backs to trace__event_id, as we're not
      interested at all in what is present in the
      /sys/kernel/debug/tracing/events in the workstation doing the analysis,
      just in what is in the perf.data file.
      
      This patch also introduces perf_session__set_tracepoints_handlers that
      is the perf perf.data/session way to associate handlers to tracepoint
      events by resolving their IDs using the events descriptions stored in a
      perf.data file. Make 'perf sched' use it.
      Reported-by: NDmitry Antipov <dmitry.antipov@linaro.org>
      Tested-by: NDmitry Antipov <dmitry.antipov@linaro.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: linaro-dev@lists.linaro.org
      Cc: patches@linaro.org
      Link: http://lkml.kernel.org/r/20120625232016.GA28525@infradead.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      da378962
  8. 20 6月, 2012 2 次提交
  9. 11 6月, 2012 1 次提交
  10. 31 5月, 2012 4 次提交
    • J
      perf session: Handle endianity swap on sample_id_all header data · 268fb20f
      Jiri Olsa 提交于
      Adding endianity swapping for event header attached via sample_id_all.
      
      Currently we dont do that and it's causing wrong data to be read when
      running report on architecture with different endianity than the record.
      
      The perf is currently able to process 32-bit PPC samples on 32-bit
      and 64-bit x86.
      
      Together with other endianity patches, this change fixies perf report
      discrepancies on origin and target systems as described in test 1
      below, e.g. following perf report diff:
      
      ...
            0.12%               ps  [kernel.kallsyms]    [k] clear_page
      -     0.12%              awk  bash                 [.] alloc_word_desc
      +     0.12%              awk  bash                 [.] yyparse
            0.11%   beah-rhts-task  libpython2.6.so.1.0  [.] 0x5560e
            0.10%             perf  libc-2.12.so         [.] __ctype_toupper_loc
      -     0.09%  rhts-test-runne  bash                 [.] maybe_make_export_env
      +     0.09%  rhts-test-runne  bash                 [.] 0x385a0
            0.09%               ps  [kernel.kallsyms]    [k] page_fault
      ...
      
      Note, running following to test perf endianity handling:
      test 1)
        - origin system:
          # perf record -a -- sleep 10 (any perf record will do)
          # perf report > report.origin
          # perf archive perf.data
      
        - copy the perf.data, report.origin and perf.data.tar.bz2
          to a target system and run:
          # tar xjvf perf.data.tar.bz2 -C ~/.debug
          # perf report > report.target
          # diff -u report.origin report.target
      
        - the diff should produce no output
          (besides some white space stuff and possibly different
           date/TZ output)
      
      test 2)
        - origin system:
          # perf record -ag -fo /tmp/perf.data -- sleep 1
        - mount origin system root to the target system on /mnt/origin
        - target system:
          # perf script --symfs /mnt/origin -I -i /mnt/origin/tmp/perf.data \
           --kallsyms /mnt/origin/proc/kallsyms
        - complete perf.data header is displayed
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Tested-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1338380624-7443-3-git-send-email-jolsa@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      268fb20f
    • N
      perf tools: Check if callchain is corrupted · 114067b6
      Namhyung Kim 提交于
      We faced segmentation fault on perf top -G at very high sampling rate
      due to a corrupted callchain. While the root cause was not revealed (I
      failed to figure it out), this patch tries to protect us from the
      segfault on such cases.
      Reported-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NNamhyung Kim <namhyung.kim@lge.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Sunjin Yang <fan4326@gmail.com>
      Link: http://lkml.kernel.org/r/1338443007-24857-2-git-send-email-namhyung.kim@lge.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      114067b6
    • N
      perf callchain: Make callchain cursors TLS · 47260645
      Namhyung Kim 提交于
      perf top -G has a race on callchain cursor between main thread and
      display thread. Since the callchain cursors are used locally make them
      thread-local data would solve the problem.
      Signed-off-by: NNamhyung Kim <namhyung.kim@lge.com>
      Reported-by: NSunjin Yang <fan4326@gmail.com>
      Suggested-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Sunjin Yang <fan4326@gmail.com>
      Link: http://lkml.kernel.org/r/1338443007-24857-1-git-send-email-namhyung.kim@lge.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      47260645
    • D
      perf script: Fix regression in callchain dso name · 52deff71
      David Ahern 提交于
      $ perf script -i /tmp/perf.data
      ...
      gcc 13623 544315.062858: context-switches:
          ffffffff815f65c9 __schedule ([kernel.kallsyms])
          ffffffff81087cea __cond_resched ([kernel.kallsyms])
          ffffffff815f6b92 _cond_resched ([kernel.kallsyms])
          ffffffff815fb87a do_page_fault ([kernel.kallsyms])
          ffffffff815f8465 page_fault ([kernel.kallsyms])
              2b7a71ea0303 _dl_lookup_symbol_x ([kernel.kallsyms])
              2b7a71ea1eb5 _dl_relocate_object ([kernel.kallsyms])
              2b7a71e99b2e dl_main ([kernel.kallsyms])
              2b7a71eab7f4 _dl_sysdep_start ([kernel.kallsyms])
      
      All DSO's in a callchain are printed as [kernel.kallsyms].
      
      git bisect chased it to:
      
      547a92e0 is the first bad commit
      commit 547a92e0
      Author: Akihiro Nagai <akihiro.nagai.hw@hitachi.com>
      Date:   Mon Jan 30 13:42:57 2012 +0900
      
          perf script: Unify the expressions indicating "unknown"
      
          The perf script command uses various expressions to indicate "unknown".
      
          It is unfriendly for user scripts to parse it. So, this patch unifies
          the expressions to "[unknown]".
      
      Looks like a copy-paste in that the other references use al.map but this one
      should be node->map.
      
      With this patch you get:
      
      $ perf script -i /tmp/perf.data
      ...
      gcc 13623 544315.062858: context-switches:
          ffffffff815f65c9 __schedule ([kernel.kallsyms])
          ffffffff81087cea __cond_resched ([kernel.kallsyms])
          ffffffff815f6b92 _cond_resched ([kernel.kallsyms])
          ffffffff815fb87a do_page_fault ([kernel.kallsyms])
          ffffffff815f8465 page_fault ([kernel.kallsyms])
              2b7a71ea0303 _dl_lookup_symbol_x (/lib64/ld-2.14.90.so)
              2b7a71ea1eb5 _dl_relocate_object (/lib64/ld-2.14.90.so)
              2b7a71e99b2e dl_main (/lib64/ld-2.14.90.so)
              2b7a71eab7f4 _dl_sysdep_start (/lib64/ld-2.14.90.so)
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Akihiro Nagai <akihiro.nagai.hw@hitachi.com>
      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>
      Link: http://lkml.kernel.org/r/1338353906-60706-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      52deff71
  11. 22 5月, 2012 2 次提交
    • S
      perf tools: Fix piped mode read code · 444d2866
      Stephane Eranian 提交于
      In __perf_session__process_pipe_events(), there was a risk we would read
      more than what a union perf_event struct can hold. this could happen in
      case, perf is reading a file which contains new record types it does not
      know about and which are larger than anything it knows about.
      
      In general, perf is supposed to skip records it does not understand, but
      in pipe mode, those have to be read and ignored.  The fixed size header
      contains the size of the record, but that size may be larger than union
      perf_event, yet it was used as the backing to the read in:
      
        union perf_event event;
        void *p;
      
        size = event->header.size;
      
        p = &event;
        p += sizeof(struct perf_event_header);
        if (size - sizeof(struct perf_event_header)) {
          err = readn(self->fd, p, size - sizeof(struct perf_event_header));
      
      We fix this by allocating a buffer based on the size reported in the
      header. We reuse the buffer as much as we can. We realloc in case it
      becomes too small. In the  common case, the performance impact is
      negligible.
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1337081295-10303-3-git-send-email-eranian@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      444d2866
    • J
      perf tools: Carry perf_event_attr bitfield throught different endians · e108c66e
      Jiri Olsa 提交于
      When the perf data file is read cross architectures, the
      perf_event__attr_swap function takes care about endianness of all the
      struct fields except the bitfield flags.
      
      The bitfield flags need to be transformed as well, since the bitfield
      binary storage differs for both endians.
      
      ABI says:
        Bit-fields are allocated from right to left (least to most significant)
        on little-endian implementations and from left to right (most to least
        significant) on big-endian implementations.
      
      The above seems to be byte specific, so we need to reverse each byte of
      the bitfield. 'Internet' also says this might be implementation specific
      and we probably need proper fix and carry perf_event_attr bitfield flags
      in separate data file FEAT_ section. Thought this seems to work for now.
      
      Note, running following to test perf endianity handling:
      test 1)
        - origin system:
          # perf record -a -- sleep 10 (any perf record will do)
          # perf report > report.origin
          # perf archive perf.data
      
        - copy the perf.data, report.origin and perf.data.tar.bz2
          to a target system and run:
          # tar xjvf perf.data.tar.bz2 -C ~/.debug
          # perf report > report.target
          # diff -u report.origin report.target
      
        - the diff should produce no output
          (besides some white space stuff and possibly different
           date/TZ output)
      
      test 2)
        - origin system:
          # perf record -ag -fo /tmp/perf.data -- sleep 1
        - mount origin system root to the target system on /mnt/origin
        - target system:
          # perf script --symfs /mnt/origin -I -i /mnt/origin/tmp/perf.data \
           --kallsyms /mnt/origin/proc/kallsyms
        - complete perf.data header is displayed
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Reviewed-by: NDavid Ahern <dsahern@gmail.com>
      Tested-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Corey Ashford <cjashfor@linux.vnet.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1337151548-2396-3-git-send-email-jolsa@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e108c66e
  12. 04 5月, 2012 1 次提交
  13. 12 4月, 2012 1 次提交
  14. 11 4月, 2012 1 次提交
  15. 23 3月, 2012 1 次提交
  16. 09 3月, 2012 3 次提交
  17. 14 2月, 2012 1 次提交
  18. 31 1月, 2012 2 次提交
  19. 04 1月, 2012 1 次提交
  20. 24 12月, 2011 2 次提交
  21. 28 11月, 2011 6 次提交