1. 24 7月, 2012 1 次提交
  2. 05 7月, 2012 3 次提交
  3. 04 7月, 2012 1 次提交
  4. 03 7月, 2012 2 次提交
    • H
      perf bench: Fix confused variable namings and descriptions in mem subsystem · 17d7a112
      Hitoshi Mitake 提交于
      As Namhyung Kim pointed, there are confused namings and descriptions of words
      "cycle" and "clock" in mem-memset.c and mem-memcpy.c.
      
      With the option "-c" (or "--clock", now renamed as "--cycle"), mem subsystem
      measures cost of memset() and memcpy() with cpu-cycles event.
      
      But current mem subsystem source code contains lots of confused variable
      namings and descriptions with "clock" (e.g. the variable use_clock). This is a
      very bad style because there is another software event named "cpu-clock". This
      patch replaces wrong usage of "clock" to "cycle".
      
      v2: modified Documentation/perf-bench.txt for the descriptions of
      --cycle option
      Signed-off-by: NHitoshi Mitake <h.mitake@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1341236777-18457-1-git-send-email-h.mitake@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      17d7a112
    • D
      perf kvm: Fix segfault with report and mixed guestmount use · 7ed97ad4
      David Ahern 提交于
      Using the guestmount option on record:
          $ perf kvm --guest --host --guestmount=/tmp/guest-mount record -ag
      
      But not the subsequent report:
          $ perf kvm report
      
      causes a SEGFAULT in the usual place:
      (gdb) bt
      0  0x0000000000470356 in machine__mmap_name (self=0x0, bf=0x7fffffffbdb0 " z\370\367\377\177", size=
          4096) at util/map.c:712
      1  0x00000000004453e8 in perf_event__process_kernel_mmap (tool=0x7fffffffde10, event=0x7ffff7f87e38,
          machine=0x0) at util/event.c:550
      2  0x00000000004458c9 in perf_event__process_mmap (tool=0x7fffffffde10, event=0x7ffff7f87e38, sample=
          0x7fffffffd2a0, machine=0x0) at util/event.c:656
      3  0x00000000004733e0 in perf_session_deliver_event (session=0x91aca0, event=0x7ffff7f87e38, sample=
          0x7fffffffd2a0, tool=0x7fffffffde10, file_offset=7736) at util/session.c:979
      ...
      
      The MMAP events in this case already contain the full path to the
      module. No need to require it for the report path to.
      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>
      Link: http://lkml.kernel.org/r/1341241977-71535-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7ed97ad4
  5. 02 7月, 2012 2 次提交
    • 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
    • D
      perf script: Fix format regression due to libtraceevent merge · 76a8349d
      David Ahern 提交于
      Consider the commands:
          perf record -e sched:sched_switch -fo /tmp/perf.data  -a -- sleep 1
          perf script -i /tmp/perf.data
      
      In v3.4 the output has the form (lines wrapped here)
          perf 29214 [005] 821043.582596: sched_switch:
      prev_comm=perf prev_pid=29214 prev_prio=120
      prev_state=S ==> next_comm=swapper/5 next_pid=0 next_prio=120
      
      In 3.5 that same line has become:
          perf 29214 [005] 821043.582596: sched_switch:
      <...>-29214 [005]     0.000000000: sched_switch:
      prev_comm=perf prev_pid=29214 prev_prio=120
      prev_state=S ==> next_comm=swapper/5 next_pid=0 next_prio=120
      
      Note the duplicates in the output -- pid, cpu, event name. With
      this patch the v3.4 output is restored:
          perf 29214 [005] 821043.582596: sched_switch:
      prev_comm=perf prev_pid=29214 prev_prio=120
      prev_state=S ==> next_comm=swapper/5 next_pid=0 next_prio=120
      
      v3:
      Remove that pesky newline too. Output now matches v3.4 (pre-libtracevent).
      
      v2:
      Change print_trace_event function local to perf per Steve's comments.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1339698977-68962-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      76a8349d
  6. 30 6月, 2012 6 次提交
  7. 28 6月, 2012 5 次提交
  8. 26 6月, 2012 2 次提交
  9. 20 6月, 2012 18 次提交