1. 23 1月, 2018 1 次提交
  2. 19 1月, 2018 1 次提交
    • A
      perf bpf: Don't warn about unavailability of builtin clang, just fallback · 87252323
      Arnaldo Carvalho de Melo 提交于
      When clang is not linked with 'perf' we should just add a debug message
      about that before doing the fallback to calling the external compiler.
      
      I.e. just the "-95" warning below gets turned into a debug message:
      
        # cat sys_enter_open.c
        #include "bpf.h"
      
        SEC("syscalls:sys_enter_open")
        int func(void *ctx)
        {
      	struct {
      		char *ptr;
      		char path[256];
      	} filename = {
      		.ptr = *((char **)(ctx + 16)),
      	};
      	int len = bpf_probe_read_str(filename.path, sizeof(filename.path), filename.ptr);
      	if (len > 0) {
      		if (len == 1)
      			perf_event_output(ctx, &__bpf_stdout__, BPF_F_CURRENT_CPU, &filename, len + sizeof(filename.ptr));
      		else if (len < 256)
      			perf_event_output(ctx, &__bpf_stdout__, BPF_F_CURRENT_CPU, &filename, len + sizeof(filename.ptr));
              }
      	return 0;
        }
        # trace -e open,sys_enter_open.c
        bpf: builtin compilation failed: -95, try external compiler
           0.000 (         ): __bpf_stdout__:@......./proc/self/task/11160/comm..)
           0.014 ( 0.116 ms): qemu-system-x8/6721 open(filename: /proc/self/task/11160/comm, flags: RDWR) = 91
        2335.411 (         ): __bpf_stdout__:FB..~.../etc/resolv.conf....)
        2335.421 ( 0.030 ms): chronyd/883 open(filename: /etc/resolv.conf, flags: CLOEXEC) = 5
      ^C#
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-z5aak9oay448ffj37giz94yr@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      87252323
  3. 18 1月, 2018 6 次提交
  4. 17 1月, 2018 25 次提交
  5. 13 1月, 2018 4 次提交
    • A
      perf trace: Fix setting of --call-graph/--max-stack for non-syscall events · 08e26396
      Arnaldo Carvalho de Melo 提交于
      The raw_syscalls:sys_{enter,exit} were first supported in 'perf trace',
      together with minor and major page faults, then we supported
      --call-graph, then --max-stack, but when the other tracepoints got
      supported, and bpf, etc, I forgot to make those global call-graph
      settings apply to them.
      
      Fix it by realizing that the global --max-stack and --call-graph
      settings are done via:
      
              OPT_CALLBACK(0, "call-graph", &trace.opts,
                           "record_mode[,record_size]", record_callchain_help,
                           &record_parse_callchain_opt),
      
      And then, when we go to parse the events in -e via:
      
              OPT_CALLBACK('e', "event", &trace, "event",
                           "event/syscall selector. use 'perf list' to list available events",
                           trace__parse_events_option),
      
      And trace__parse_sevents_option() calls:
      
                      struct option o = OPT_CALLBACK('e', "event", &trace->evlist, "event",
                                                     "event selector. use 'perf list' to list available events",
                                                     parse_events_option);
                      err = parse_events_option(&o, lists[0], 0);
      
      parse_events_option() will override the global --call-graph and
      --max-stack if the "call-graph" and/or "max-stack" terms are in the
      event definition, such as in the probe_libc:inet_pton event in one of the
      examples below (-e probe_libc:inet_pton/max-stack=2).
      
      Before:
      
        # perf trace --mmap 1024 --call-graph dwarf -e sendto,probe_libc:inet_pton ping -6 -c 1 ::1
             1.525 (         ): probe_libc:inet_pton:(7f77f3ac9350))
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.071 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.071/0.071/0.071/0.000 ms
             1.677 ( 0.081 ms): ping/31296 sendto(fd: 3, buff: 0x55681b652720, len: 64, addr: 0x55681b650640, addr_len: 28) = 64
                                               __libc_sendto (/usr/lib64/libc-2.26.so)
                                               [0xffffaa97e4bc9cef] (/usr/bin/ping)
                                               [0xffffaa97e4bc656d] (/usr/bin/ping)
                                               [0xffffaa97e4bc7d0a] (/usr/bin/ping)
                                               [0xffffaa97e4bca447] (/usr/bin/ping)
                                               [0xffffaa97e4bc2f91] (/usr/bin/ping)
                                               __libc_start_main (/usr/lib64/libc-2.26.so)
                                               [0xffffaa97e4bc3379] (/usr/bin/ping)
        #
      
      After:
      
        # perf trace --mmap 1024 --call-graph dwarf -e sendto,probe_libc:inet_pton ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.089 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.089/0.089/0.089/0.000 ms
             1.955 (         ): probe_libc:inet_pton:(7f383a311350))
                                               __inet_pton (inlined)
                                               gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                               __GI_getaddrinfo (inlined)
                                               [0xffffaa5d91444f3f] (/usr/bin/ping)
                                               __libc_start_main (/usr/lib64/libc-2.26.so)
                                               [0xffffaa5d91445379] (/usr/bin/ping)
             2.140 ( 0.101 ms): ping/32047 sendto(fd: 3, buff: 0x55a26edd0720, len: 64, addr: 0x55a26edce640, addr_len: 28) = 64
                                               __libc_sendto (/usr/lib64/libc-2.26.so)
                                               [0xffffaa5d9144bcef] (/usr/bin/ping)
                                               [0xffffaa5d9144856d] (/usr/bin/ping)
                                               [0xffffaa5d91449d0a] (/usr/bin/ping)
                                               [0xffffaa5d9144c447] (/usr/bin/ping)
                                               [0xffffaa5d91444f91] (/usr/bin/ping)
                                               __libc_start_main (/usr/lib64/libc-2.26.so)
                                               [0xffffaa5d91445379] (/usr/bin/ping)
        #
      
      Same thing for --max-stack, the global one:
      
        # perf trace --max-stack 3 -e sendto,probe_libc:inet_pton ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.097 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.097/0.097/0.097/0.000 ms
             1.577 (         ): probe_libc:inet_pton:(7f32f3957350))
                                               __inet_pton (inlined)
                                               gaih_inet.constprop.7 (/usr/lib64/libc-2.26.so)
                                               __GI_getaddrinfo (inlined)
             1.738 ( 0.108 ms): ping/32103 sendto(fd: 3, buff: 0x55c3132d7720, len: 64, addr: 0x55c3132d5640, addr_len: 28) = 64
                                               __libc_sendto (/usr/lib64/libc-2.26.so)
                                               [0xffffaa3cecf44cef] (/usr/bin/ping)
                                               [0xffffaa3cecf4156d] (/usr/bin/ping)
        #
      
      And then setting up a global setting (dwarf, max-stack=4), that will
      affect the raw_syscall:sys_enter for the 'sendto' syscall and that will
      be overriden in the probe_libc:inet_pton call to just one entry.
      
        # perf trace --max-stack=4 --call-graph dwarf -e sendto -e probe_libc:inet_pton/max-stack=1/ ping -6 -c 1 ::1
        PING ::1(::1) 56 data bytes
        64 bytes from ::1: icmp_seq=1 ttl=64 time=0.090 ms
      
        --- ::1 ping statistics ---
        1 packets transmitted, 1 received, 0% packet loss, time 0ms
        rtt min/avg/max/mdev = 0.090/0.090/0.090/0.000 ms
             2.140 (         ): probe_libc:inet_pton:(7f9fe9337350))
                                               __GI___inet_pton (/usr/lib64/libc-2.26.so)
             2.283 ( 0.103 ms): ping/31804 sendto(fd: 3, buff: 0x55c7f3e19720, len: 64, addr: 0x55c7f3e17640, addr_len: 28) = 64
                                               __libc_sendto (/usr/lib64/libc-2.26.so)
                                               [0xffffaa380c402cef] (/usr/bin/ping)
                                               [0xffffaa380c3ff56d] (/usr/bin/ping)
                                               [0xffffaa380c400d0a] (/usr/bin/ping)
        #
      
      Install iputils-debuginfo to get those /usr/bin/ping addresses resolved,
      those routines are not on its .dymsym nor .symtab :-)
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-qgl2gse8elhh9zztw4ajopg3@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      08e26396
    • A
      perf evsel: Check if callchain is enabled before setting it up · 1688c2fd
      Arnaldo Carvalho de Melo 提交于
      The construct:
      
      	if (callchain_param)
      		perf_evsel__config_callchain(evsel, opts, &callchain_param);
      
      happens in several places, so make perf_evsel__config_callchain() work
      just like free(NULL), do nothing if param->enabled is not set.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-ykk0qzxnxwx3o611ctjnmxav@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1688c2fd
    • J
      perf tools: Fix copyfile_offset update of output offset · fa1195cc
      Jiri Olsa 提交于
      We need to increase output offset in each iteration, not decrease it as
      we currently do.
      
      I guess we were lucky to finish in most cases in first iteration, so the
      bug never showed. However it shows a lot when working with big (~4GB)
      size data.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: 9c9f5a2f ("perf tools: Introduce copyfile_offset() function")
      Link: http://lkml.kernel.org/r/20180109133923.25406-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fa1195cc
    • A
      perf trace: No need to set PERF_SAMPLE_IDENTIFIER explicitely · 236d812c
      Arnaldo Carvalho de Melo 提交于
      Since 75562573 ("perf tools: Add support for
      PERF_SAMPLE_IDENTIFIER") we don't need explicitely set
      PERF_SAMPLE_IDENTIFIER, as perf_evlist__config() will do this for us,
      i.e. when there are more than one evsel in an evlist, it will check if
      some evsel has a sample_type different than the one on the first evsel
      in the list, setting PERF_SAMPLE_IDENTIFIER in that case.
      
      So, to simplify 'perf trace' codebase, ditch that check.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hendrick Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-12xq6orhwttee2tdtu96ucrp@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      236d812c
  6. 12 1月, 2018 3 次提交
    • K
      perf script python: Add script to profile and resolve physical mem type · 41013f0c
      Kan Liang 提交于
      There could be different types of memory in the system. E.g normal
      System Memory, Persistent Memory. To understand how the workload maps to
      those memories, it's important to know the I/O statistics of them.  Perf
      can collect physical addresses, but those are raw data.  It still needs
      extra work to resolve the physical addresses.  Provide a script to
      facilitate the physical addresses resolving and I/O statistics.
      
      Profile with MEM_INST_RETIRED.ALL_LOADS or MEM_UOPS_RETIRED.ALL_LOADS
      event if any of them is available.
      
      Look up the /proc/iomem and resolve the physical address.  Provide
      memory type summary.
      
      Here is an example output:
      
        # perf script report mem-phys-addr
        Event: mem_inst_retired.all_loads:P
        Memory type                                    count   percentage
        ----------------------------------------  -----------  -----------
        System RAM                                        74        53.2%
        Persistent Memory                                 55        39.6%
        N/A
      
        ---
      
      Changes since V2:
       - Apply the new license rules.
       - Add comments for globals
      
      Changes since V1:
       - Do not mix DLA and Load Latency. Do not compare the loads and stores.
         Only profile the loads.
       - Use event name to replace the RAW event
      Signed-off-by: NKan Liang <Kan.liang@intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Philippe Ombredanne <pombredanne@nexb.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: https://lkml.kernel.org/r/1515099595-34770-1-git-send-email-kan.liang@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      41013f0c
    • L
      perf evlist: Remove trailing semicolon · dd8bd53a
      Luis de Bethencourt 提交于
      The trailing semicolon is an empty statement that does no operation.
      Removing it since it doesn't do anything.
      Signed-off-by: NLuis de Bethencourt <luisbg@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180111155020.9782-1-luisbg@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      dd8bd53a
    • K
      perf/x86/rapl: Fix Haswell and Broadwell server RAPL event · 1289e0e2
      Kan Liang 提交于
      Perf-fuzzer triggers non-existent MSR access in RAPL driver on
      Haswell-EX.
      
      Haswell/Broadwell server and client have differnt RAPL events.
      Since 'commit 7f2236d0 ("perf/x86/rapl: Use Intel family macros for
      RAPL")', it accidentally assign RAPL client events to server.
      Signed-off-by: NKan Liang <kan.liang@linux.intel.com>
      Acked-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Linux-kernel@vger.kernel.org
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      1289e0e2