1. 16 3月, 2017 3 次提交
    • A
      perf script: Add 'brstackinsn' for branch stacks · 48d02a1d
      Andi Kleen 提交于
      Implement printing instruction sequences as hex dump for branch stacks.
      
      This relies on the x86 instruction decoder used by the PT decoder to
      find the lengths of instructions to dump them individually.
      
      This is good enough for pattern matching.
      
      This allows to study hot paths for individual samples, together with
      branch misprediction and cycle count / IPC information if available (on
      Skylake systems).
      
        % perf record -b ...
        % perf script -F brstackinsn
        ...
          read_hpet+67:
                ffffffff9905b843        insn: 74 ea                     # PRED
                ffffffff9905b82f        insn: 85 c9
                ffffffff9905b831        insn: 74 12
                ffffffff9905b833        insn: f3 90
                ffffffff9905b835        insn: 48 8b 0f
                ffffffff9905b838        insn: 48 89 ca
                ffffffff9905b83b        insn: 48 c1 ea 20
                ffffffff9905b83f        insn: 39 f2
                ffffffff9905b841        insn: 89 d0
                ffffffff9905b843        insn: 74 ea                     # PRED
      
      Only works when no special branch filters are specified.
      
      Occasionally the path does not reach up to the sample IP, as the LBRs
      may be frozen before executing a final jump. In this case we print a
      special message.
      
      The instruction dumper piggy backs on the existing infrastructure from
      the IP PT decoder.
      
      An earlier iteration of this patch relied on a disassembler, but this
      version only uses the existing instruction decoder.
      
      Committer note:
      
      Added hint about how to get suitable perf.data files for use with
      '-F brstackinsm':
      
        $ perf record usleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.018 MB perf.data (8 samples) ]
        $
        $ perf script -F brstackinsn
        Display of branch stack assembler requested, but non all-branch filter set
        Hint: run 'perf record -b ...'
        $
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Link: http://lkml.kernel.org/r/20170223234634.583-1-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      48d02a1d
    • S
      perf tools: Make perf_event__synthesize_mmap_events() scale · 88b897a3
      Stephane Eranian 提交于
      This patch significantly improves the execution time of
      perf_event__synthesize_mmap_events() when running perf record on systems
      where processes have lots of threads.
      
      It just happens that cat /proc/pid/maps support uses a O(N^2) algorithm to
      generate each map line in the maps file.  If you have 1000 threads, then you
      have necessarily 1000 stacks.  For each vma, you need to check if it
      corresponds to a thread's stack.  With a large number of threads, this can take
      a very long time. I have seen latencies >> 10mn.
      
      As of today, perf does not use the fact that a mapping is a stack, therefore we
      can work around the issue by using /proc/pid/tasks/pid/maps.  This entry does
      not try to map a vma to stack and is thus much faster with no loss of
      functonality.
      
      The proc-map-timeout logic is kept in case users still want some upper limit.
      
      In V2, we fix the file path from /proc/pid/tasks/pid/maps to actual
      /proc/pid/task/pid/maps, tasks -> task.  Thanks Arnaldo for catching this.
      
      Committer note:
      
      This problem seems to have been elliminated in the kernel since commit :
      b18cb64e ("fs/proc: Stop trying to report thread stacks").
      Signed-off-by: NStephane Eranian <eranian@google.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20170315135059.GC2177@redhat.com
      Link: http://lkml.kernel.org/r/1489598233-25586-1-git-send-email-eranian@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      88b897a3
    • R
      perf probe: Introduce util func is_sdt_event() · af9100ad
      Ravi Bangoria 提交于
      Factor out the SDT event name checking routine as is_sdt_event().
      Signed-off-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/20170314150658.7065-2-ravi.bangoria@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      af9100ad
  2. 15 3月, 2017 7 次提交
    • N
      perf powerpc: Choose local entry point with kretprobes · 44ca9341
      Naveen N. Rao 提交于
      perf now uses an offset from _text/_stext for kretprobes if the kernel
      supports it, rather than the actual function name. As such, let's choose
      the LEP for powerpc ABIv2 so as to ensure the probe gets hit. Do it only
      if the kernel supports specifying offsets with kretprobes.
      Signed-off-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/7445b5334673ef5404ac1d12609bad4d73d2b567.1488961018.git.naveen.n.rao@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      44ca9341
    • N
      perf kretprobes: Offset from reloc_sym if kernel supports it · 7ab31d94
      Naveen N. Rao 提交于
      We indicate support for accepting sym+offset with kretprobes through a
      line in ftrace README. Parse the same to identify support and choose the
      appropriate format for kprobe_events.
      
      As an example, without this perf patch, but with the ftrace changes:
      
        naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/tracing/README | grep kretprobe
        place (kretprobe): [<module>:]<symbol>[+<offset>]|<memaddr>
        naveen@ubuntu:~/linux/tools/perf$
        naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
        probe-definition(0): do_open%return
        symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /boot/vmlinux for symbols
        Open Debuginfo file: /boot/vmlinux
        Try to find probe point from debuginfo.
        Matched function: do_open [2d0c7d8]
        Probe point found: do_open+0
        Matched function: do_open [35d76b5]
        found inline addr: 0xc0000000004ba984
        Failed to find "do_open%return",
         because do_open is an inlined function and has no return point.
        An error occurred in debuginfo analysis (-22).
        Trying to use symbols.
        Opening /sys/kernel/debug/tracing//kprobe_events write=1
        Writing event: r:probe/do_open do_open+0
        Writing event: r:probe/do_open_1 do_open+0
        Added new events:
          probe:do_open        (on do_open%return)
          probe:do_open_1      (on do_open%return)
      
        You can now use it in all perf tools, such as:
      
      	  perf record -e probe:do_open_1 -aR sleep 1
      
        naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
        c000000000041370  k  kretprobe_trampoline+0x0    [OPTIMIZED]
        c0000000004433d0  r  do_open+0x0    [DISABLED]
        c0000000004433d0  r  do_open+0x0    [DISABLED]
      
      And after this patch (and the subsequent powerpc patch):
      
        naveen@ubuntu:~/linux/tools/perf$ sudo ./perf probe -v do_open%return
        probe-definition(0): do_open%return
        symbol:do_open file:(null) line:0 offset:0 return:1 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (8 entries long)
        Using /boot/vmlinux for symbols
        Open Debuginfo file: /boot/vmlinux
        Try to find probe point from debuginfo.
        Matched function: do_open [2d0c7d8]
        Probe point found: do_open+0
        Matched function: do_open [35d76b5]
        found inline addr: 0xc0000000004ba984
        Failed to find "do_open%return",
         because do_open is an inlined function and has no return point.
        An error occurred in debuginfo analysis (-22).
        Trying to use symbols.
        Opening /sys/kernel/debug/tracing//README write=0
        Opening /sys/kernel/debug/tracing//kprobe_events write=1
        Writing event: r:probe/do_open _text+4469712
        Writing event: r:probe/do_open_1 _text+4956248
        Added new events:
          probe:do_open        (on do_open%return)
          probe:do_open_1      (on do_open%return)
      
        You can now use it in all perf tools, such as:
      
      	  perf record -e probe:do_open_1 -aR sleep 1
      
        naveen@ubuntu:~/linux/tools/perf$ sudo cat /sys/kernel/debug/kprobes/list
        c000000000041370  k  kretprobe_trampoline+0x0    [OPTIMIZED]
        c0000000004433d0  r  do_open+0x0    [DISABLED]
        c0000000004ba058  r  do_open+0x8    [DISABLED]
      Signed-off-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/496ef9f33c1ab16286ece9dd62aa672807aef91c.1488961018.git.naveen.n.rao@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7ab31d94
    • N
      perf probe: Factor out the ftrace README scanning · 3da3ea7a
      Naveen N. Rao 提交于
      Simplify and separate out the ftrace README scanning logic into a
      separate helper. This is used subsequently to scan for all patterns of
      interest and to cache the result.
      
      Since we are only interested in availability of probe argument type x,
      we will only scan for that.
      Signed-off-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Link: http://lkml.kernel.org/r/6dc30edc747ba82a236593be6cf3a046fa9453b5.1488961018.git.naveen.n.rao@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3da3ea7a
    • B
      perf sched timehist: Add --next option · 292c4a8f
      Brendan Gregg 提交于
      The --next option shows the next task for each context switch, providing
      more context for the sequence of scheduler events.
      
        $ perf sched timehist --next | head
        Samples do not have callchains.
             time  cpu task name  waittime schdelay run time
                       [tid/pid]     (msec) (msec) (msec)
        ---------- --- ---------- --------- ------ -----
        374.793792 [0] <idle>         0.000  0.000 0.000 next: rngd[1524]
        374.793801 [0] rngd[1524]     0.000  0.000 0.009 next: swapper/0[0]
        374.794048 [7] <idle>         0.000  0.000 0.000 next: yes[30884]
        374.794066 [7] yes[30884]     0.000  0.000 0.018 next: swapper/7[0]
        374.794126 [2] <idle>         0.000  0.000 0.000 next: rngd[1524]
        374.794140 [2] rngd[1524]     0.325  0.006 0.013 next: swapper/2[0]
        374.794281 [3] <idle>         0.000  0.000 0.000 next: perf[31070]
      Signed-off-by: NBrendan Gregg <bgregg@netflix.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1489456589-32555-1-git-send-email-bgregg@netflix.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      292c4a8f
    • H
      perf tools: Add 'cgroup_id' sort order keyword · d890a98c
      Hari Bathini 提交于
      This patch introduces a cgroup identifier entry field in perf report to
      identify or distinguish data of different cgroups. It uses the device
      number and inode number of cgroup namespace, included in perf data with
      the new PERF_RECORD_NAMESPACES event, as cgroup identifier.
      
      With the assumption that each container is created with it's own cgroup
      namespace,  this allows assessment/analysis of multiple containers at
      once.
      
      A simple test for this would be to clone a few processes passing
      SIGCHILD & CLONE_NEWCROUP flags to each of them, execute shell and run
      different workloads  on each of those contexts,  while running perf
      record command with --namespaces option.
      
      Shown below is the output of perf report, sorted with cgroup identifier,
      on perf.data generated with the above test scenario, clearly indicating
      one context's considerable use of kernel memory in comparison with
      others:
      
      	$ perf report -s cgroup_id,sample --stdio
      	#
      	# Total Lost Samples: 0
      	#
      	# Samples: 5K of event 'kmem:kmalloc'
      	# Event count (approx.): 5965
      	#
      	# Overhead  cgroup id (dev/inode)       Samples
      	# ........  .....................  ............
      	#
      	    81.27%  3/0xeffffffb                   4848
      	    16.24%  3/0xf00000d0                    969
      	     1.16%  3/0xf00000ce                     69
      	     0.82%  3/0xf00000cf                     49
      	     0.50%  0/0x0                            30
      
      While this is a start, there is further scope of improving this. For
      example, instead of cgroup namespace's device and inode numbers, dev
      and inode numbers of some or all namespaces may be used to distinguish
      which processes are running in a given container context.
      
      Also, scripts to map device and inode info to containers sounds
      plausible for better tracing of containers.
      Signed-off-by: NHari Bathini <hbathini@linux.vnet.ibm.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sargun Dhillon <sargun@sargun.me>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/148891933338.25309.756882900782042645.stgit@hbathini.in.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d890a98c
    • H
      perf script: Add script print support for namespace events · 96a44bbc
      Hari Bathini 提交于
      Introduce a new option to display events of type PERF_RECORD_NAMESPACES
      and update perf-script documentation accordingly.
      
      Shown below is output (trimmed) of perf script command with the newly
      introduced option, on perf.data generated with perf record command using
      --namespaces option.
      
        $ perf script --show-namespace-events
            swapper   0 [000]     0.000000: PERF_RECORD_NAMESPACES 1/1 - nr_namespaces: 7
                      [0/net: 3/0xf000001c, 1/uts: 3/0xeffffffe, 2/ipc: 3/0xefffffff, 3/pid: 3/0xeffffffc,
                       4/user: 3/0xeffffffd, 5/mnt: 3/0xf0000000, 6/cgroup: 3/0xeffffffb]
            swapper   0 [000]     0.000000: PERF_RECORD_NAMESPACES 2/2 - nr_namespaces: 7
                      [0/net: 3/0xf000001c, 1/uts: 3/0xeffffffe, 2/ipc: 3/0xefffffff, 3/pid: 3/0xeffffffc,
                       4/user: 3/0xeffffffd, 5/mnt: 3/0xf0000000, 6/cgroup: 3/0xeffffffb]
      
      Commiter notes:
      
      Testing it:
      
      Investigating that double PERF_RECORD_NAMESPACES for the 19155
      pid/tid... Its more than that, there are two PERF_RECORD_COMM as well,
      and with zeroed timestamps, so probably a synthesizing artifact...
      
        # perf script --show-task --show-namespace
        <SNIP>
            perf     0 [000]     0.000000: PERF_RECORD_COMM: perf:19154/19154
            perf     0 [000]     0.000000: PERF_RECORD_FORK(19155:19155):(19154:19154)
            perf     0 [000]     0.000000: PERF_RECORD_NAMESPACES 19155/19155 - nr_namespaces: 7
                [0/net: 3/0xf0000081, 1/uts: 3/0xeffffffe, 2/ipc: 3/0xefffffff, 3/pid: 3/0xeffffffc,
                 4/user: 3/0xeffffffd, 5/mnt: 3/0xf0000000, 6/cgroup: 3/0xeffffffb]
            perf     0 [000]     0.000000: PERF_RECORD_COMM: perf:19155/19155
            perf     0 [000]     0.000000: PERF_RECORD_COMM: perf:19155/19155
            perf     0 [000]     0.000000: PERF_RECORD_NAMESPACES 19155/19155 - nr_namespaces: 7
                [0/net: 3/0xf0000081, 1/uts: 3/0xeffffffe, 2/ipc: 3/0xefffffff, 3/pid: 3/0xeffffffc,
                 4/user: 3/0xeffffffd, 5/mnt: 3/0xf0000000, 6/cgroup: 3/0xeffffffb]
         swapper     0 [000]  3110.881834:          1 cycles:  ffffffffa7060bf6 native_write_msr (/lib/modules/4.11.0-rc1+/build/vmlinux)
      
        <SNIP>
      Signed-off-by: NHari Bathini <hbathini@linux.vnet.ibm.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sargun Dhillon <sargun@sargun.me>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/148891932627.25309.1941587059154176221.stgit@hbathini.in.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      96a44bbc
    • H
      perf record: Synthesize namespace events for current processes · e907caf3
      Hari Bathini 提交于
      Synthesize PERF_RECORD_NAMESPACES events for processes that were running prior
      to invocation of perf record. The data for this is taken from /proc/$PID/ns.
      These changes make way for analyzing events with regard to namespaces.
      
      Committer notes:
      
      Check if 'tool' is NULL in perf_event__synthesize_namespaces(), as in the
      test__mmap_thread_lookup case, i.e. 'perf test Lookup mmap thread".
      
      Testing it:
      
        # ps axH > /tmp/allthreads
        # perf record -a --namespaces usleep 1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 1.169 MB perf.data (8 samples) ]
        # perf report -D | grep PERF_RECORD_NAMESPACES | wc -l
        602
        # wc -l /tmp/allthreads
        601 /tmp/allthreads
        # tail /tmp/allthreads
        16951 pts/4    T      0:00 git rebase -i a033bf1bfacdaa25642e6bcc857a7d0f67cc3c92^
        16952 pts/4    T      0:00 /bin/sh /usr/libexec/git-core/git-rebase -i a033bf1bfacdaa25642e6bcc857a7d0f67cc3c92^
        17176 pts/4    T      0:00 git commit --amend --no-post-rewrite
        17204 pts/4    T      0:00 vim /home/acme/git/linux/.git/COMMIT_EDITMSG
        18939 ?        S      0:00 [kworker/2:1]
        18947 ?        S      0:00 [kworker/3:0]
        18974 ?        S      0:00 [kworker/1:0]
        19047 ?        S      0:00 [kworker/0:1]
        19152 pts/6    S+     0:00 weechat
        19153 pts/7    R+     0:00 ps axH
        # perf report -D | grep PERF_RECORD_NAMESPACES | tail
        0 0 0x125068 [0xa0]: PERF_RECORD_NAMESPACES 17176/17176 - nr_namespaces: 7
        0 0 0x1255b8 [0xa0]: PERF_RECORD_NAMESPACES 17204/17204 - nr_namespaces: 7
        0 0 0x125df0 [0xa0]: PERF_RECORD_NAMESPACES 18939/18939 - nr_namespaces: 7
        0 0 0x125f00 [0xa0]: PERF_RECORD_NAMESPACES 18947/18947 - nr_namespaces: 7
        0 0 0x126010 [0xa0]: PERF_RECORD_NAMESPACES 18974/18974 - nr_namespaces: 7
        0 0 0x126120 [0xa0]: PERF_RECORD_NAMESPACES 19047/19047 - nr_namespaces: 7
        0 0 0x126230 [0xa0]: PERF_RECORD_NAMESPACES 19152/19152 - nr_namespaces: 7
        0 0 0x129330 [0xa0]: PERF_RECORD_NAMESPACES 19154/19154 - nr_namespaces: 7
        0 0 0x12a1f8 [0xa0]: PERF_RECORD_NAMESPACES 19155/19155 - nr_namespaces: 7
        0 0 0x12b0b8 [0xa0]: PERF_RECORD_NAMESPACES 19155/19155 - nr_namespaces: 7
        #
      
      Humm, investigate why we got two record for the 19155 pid/tid...
      Signed-off-by: NHari Bathini <hbathini@linux.vnet.ibm.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sargun Dhillon <sargun@sargun.me>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/148891931111.25309.11073854609798681633.stgit@hbathini.in.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e907caf3
  3. 14 3月, 2017 1 次提交
    • H
      perf tools: Add PERF_RECORD_NAMESPACES to include namespaces related info · f3b3614a
      Hari Bathini 提交于
      Introduce a new option to record PERF_RECORD_NAMESPACES events emitted
      by the kernel when fork, clone, setns or unshare are invoked. And update
      perf-record documentation with the new option to record namespace
      events.
      
      Committer notes:
      
      Combined it with a later patch to allow printing it via 'perf report -D'
      and be able to test the feature introduced in this patch. Had to move
      here also perf_ns__name(), that was introduced in another later patch.
      
      Also used PRIu64 and PRIx64 to fix the build in some enfironments wrt:
      
        util/event.c:1129:39: error: format '%lx' expects argument of type 'long unsigned int', but argument 6 has type 'long long unsigned int' [-Werror=format=]
           ret  += fprintf(fp, "%u/%s: %lu/0x%lx%s", idx
                                               ^
      Testing it:
      
        # perf record --namespaces -a
        ^C[ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 1.083 MB perf.data (423 samples) ]
        #
        # perf report -D
        <SNIP>
        3 2028902078892 0x115140 [0xa0]: PERF_RECORD_NAMESPACES 14783/14783 - nr_namespaces: 7
                      [0/net: 3/0xf0000081, 1/uts: 3/0xeffffffe, 2/ipc: 3/0xefffffff, 3/pid: 3/0xeffffffc,
                       4/user: 3/0xeffffffd, 5/mnt: 3/0xf0000000, 6/cgroup: 3/0xeffffffb]
      
        0x1151e0 [0x30]: event: 9
        .
        . ... raw event: size 48 bytes
        .  0000:  09 00 00 00 02 00 30 00 c4 71 82 68 0c 7f 00 00  ......0..q.h....
        .  0010:  a9 39 00 00 a9 39 00 00 94 28 fe 63 d8 01 00 00  .9...9...(.c....
        .  0020:  03 00 00 00 00 00 00 00 ce c4 02 00 00 00 00 00  ................
        <SNIP>
              NAMESPACES events:          1
        <SNIP>
        #
      Signed-off-by: NHari Bathini <hbathini@linux.vnet.ibm.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Aravinda Prasad <aravinda@linux.vnet.ibm.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sargun Dhillon <sargun@sargun.me>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/148891930386.25309.18412039920746995488.stgit@hbathini.in.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f3b3614a
  4. 13 3月, 2017 5 次提交
  5. 07 3月, 2017 3 次提交
  6. 06 3月, 2017 1 次提交
  7. 04 3月, 2017 20 次提交