1. 17 Jun, 2019 31 commits
  2. 14 Jun, 2019 2 commits
  3. 13 Jun, 2019 1 commit
  4. 10 Jun, 2019 6 commits
    • Arnaldo Carvalho de Melo's avatar
      perf trace: Skip unknown syscalls when expanding strace like syscall groups · 04c41bcb
      Arnaldo Carvalho de Melo authored
      We have $INSTALL_DIR/share/perf-core/strace/groups/string files with
      syscalls that should be selected when 'string' is used, meaning, in this
      case, syscalls that receive as one of its arguments a string, like a
      pathname.
      
      But those were first selected and tested on x86_64, and end up failing
      in architectures where some of those syscalls are not available, like
      the 'access' syscall on arm64, which makes using 'perf trace -e string'
      in such archs to fail.
      
      Since this the routine doing the validation is used only when reading
      such files, do not fail when some syscall is not found in the
      syscalltbl, instead just use pr_debug() to register that in case people
      are suspicious of problems.
      
      Now using 'perf trace -e string' should work on arm64, selecting only
      the syscalls that have a string and are available on that architecture.
      Reported-by: default avatarLeo Yan <leo.yan@linaro.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Martin KaFai Lau <kafai@fb.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Mike Leach <mike.leach@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
      Cc: Yonghong Song <yhs@fb.com>
      Link: https://lkml.kernel.org/r/20190610184754.GU21245@kernel.orgSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      04c41bcb
    • Thomas Richter's avatar
      perf report: Support s390 diag event display on x86 · 180ca71c
      Thomas Richter authored
      Perf report fails to display s390 specific event numbered bd000
      on an x86 platform. For example on s390 this works without error:
      
      [root@m35lp76 perf]# uname -m
      s390x
      [root@m35lp76 perf]# ./perf record -e rbd000 -- find / >/dev/null
      [ perf record: Woken up 3 times to write data ]
      [ perf record: Captured and wrote 0.549 MB perf.data ]
      [root@m35lp76 perf]# ./perf report -D --stdio  > /dev/null
      [root@m35lp76 perf]#
      
      Transfering this perf.data file to an x86 platform and executing
      the same report command produces:
      
      [root@f29 perf]# uname -m
      x86_64
      [root@f29 perf]# ./perf report -i ~/perf.data.m35lp76 --stdio
      interpreting bpf_prog_info from systems with endianity is not yet supported
      interpreting btf from systems with endianity is not yet supported
      0x8c890 [0x8]: failed to process type: 68
      Error:
      failed to process sample
      
      Event bd000 generates auxiliary data which is stored in big endian
      format in the perf data file.
      This error is caused by missing endianess handling on the x86 platform
      when the data is displayed. Fix this by handling s390 auxiliary event
      data depending on the local platform endianness.
      
      Output after on x86:
      
      [root@f29 perf]# ./perf report -D -i ~/perf.data.m35lp76 --stdio > /dev/null
      interpreting bpf_prog_info from systems with endianity is not yet supported
      interpreting btf from systems with endianity is not yet supported
      [root@f29 perf]#
      
      Committer notes:
      
      Fix build breakage on older systems, such as CentOS:6 where using
      nesting calls to the endian.h macros end up redefining local variables:
      
        util/s390-cpumsf.c: In function 's390_cpumsf_trailer_show':
        util/s390-cpumsf.c:333: error: declaration of '__v' shadows a previous local
        util/s390-cpumsf.c:333: error: shadowed declaration is here
        util/s390-cpumsf.c:333: error: declaration of '__x' shadows a previous local
        util/s390-cpumsf.c:333: error: shadowed declaration is here
        util/s390-cpumsf.c:334: error: declaration of '__v' shadows a previous local
        util/s390-cpumsf.c:334: error: shadowed declaration is here
        util/s390-cpumsf.c:334: error: declaration of '__x' shadows a previous local
        util/s390-cpumsf.c:334: error: shadowed declaration is here
      
        [perfbuilder@455a63ef60dc perf]$ gcc -v |& tail -1
        gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC)
        [perfbuilder@455a63ef60dc perf]$
      
      Since there are several uses of
      
        be64toh(te->flags)
      
      Introduce a variable to hold that and then use it, avoiding this case
      that causes the above problems:
      
        -       local.bsdes = be16toh((be64toh(te->flags) >> 16 & 0xffff));
        +       local.bsdes = be16toh((flags >> 16 & 0xffff));
      
      Its the same construct used in s390_cpumsf_diag_show() where we have a
      'word' variable that is used just once, s390_cpumsf_basic_show() has
      lots of uses and also uses a variable to hold the result of be16toh().
      
      Some of those temp variables needed to be converted from 'unsigned long'
      to 'unsigned long long' so as to build on 32-bit arches such as
      debian:experimental-x-mipsel, the android NDK ones and
      fedora:24-x-ARC-uClibc.
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Link: http://lkml.kernel.org/r/20190522064325.25596-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      180ca71c
    • Thomas Richter's avatar
      perf report: Fix OOM error in TUI mode on s390 · 8a07aa4e
      Thomas Richter authored
      Debugging a OOM error using the TUI interface revealed this issue
      on s390:
      
      [tmricht@m83lp54 perf]$ cat /proc/kallsyms |sort
      ....
      00000001119b7158 B radix_tree_node_cachep
      00000001119b8000 B __bss_stop
      00000001119b8000 B _end
      000003ff80002850 t autofs_mount	[autofs4]
      000003ff80002868 t autofs_show_options	[autofs4]
      000003ff80002a98 t autofs_evict_inode	[autofs4]
      ....
      
      There is a huge gap between the last kernel symbol
      __bss_stop/_end and the first kernel module symbol
      autofs_mount (from autofs4 module).
      
      After reading the kernel symbol table via functions:
      
       dso__load()
       +--> dso__load_kernel_sym()
            +--> dso__load_kallsyms()
      	   +--> __dso_load_kallsyms()
      	        +--> symbols__fixup_end()
      
      the symbol __bss_stop has a start address of 1119b8000 and
      an end address of 3ff80002850, as can be seen by this debug statement:
      
        symbols__fixup_end __bss_stop start:0x1119b8000 end:0x3ff80002850
      
      The size of symbol __bss_stop is 0x3fe6e64a850 bytes!
      It is the last kernel symbol and fills up the space until
      the first kernel module symbol.
      
      This size kills the TUI interface when executing the following
      code:
      
        process_sample_event()
          hist_entry_iter__add()
            hist_iter__report_callback()
              hist_entry__inc_addr_samples()
                symbol__inc_addr_samples(symbol = __bss_stop)
                  symbol__cycles_hist()
                     annotated_source__alloc_histograms(...,
      				                symbol__size(sym),
      		                                ...)
      
      This function allocates memory to save sample histograms.
      The symbol_size() marco is defined as sym->end - sym->start, which
      results in above value of 0x3fe6e64a850 bytes and
      the call to calloc() in annotated_source__alloc_histograms() fails.
      
      The histgram memory allocation might fail, make this failure
      no-fatal and continue processing.
      
      Output before:
      [tmricht@m83lp54 perf]$ ./perf --debug stderr=1 report -vvvvv \
      					      -i ~/slow.data 2>/tmp/2
      [tmricht@m83lp54 perf]$ tail -5 /tmp/2
        __symbol__inc_addr_samples(875): ENOMEM! sym->name=__bss_stop,
      		start=0x1119b8000, addr=0x2aa0005eb08, end=0x3ff80002850,
      		func: 0
      problem adding hist entry, skipping event
      0x938b8 [0x8]: failed to process type: 68 [Cannot allocate memory]
      [tmricht@m83lp54 perf]$
      
      Output after:
      [tmricht@m83lp54 perf]$ ./perf --debug stderr=1 report -vvvvv \
      					      -i ~/slow.data 2>/tmp/2
      [tmricht@m83lp54 perf]$ tail -5 /tmp/2
         symbol__inc_addr_samples map:0x1597830 start:0x110730000 end:0x3ff80002850
         symbol__hists notes->src:0x2aa2a70 nr_hists:1
         symbol__inc_addr_samples sym:unlink_anon_vmas src:0x2aa2a70
         __symbol__inc_addr_samples: addr=0x11094c69e
         0x11094c670 unlink_anon_vmas: period++ [addr: 0x11094c69e, 0x2e, evidx=0]
         	=> nr_samples: 1, period: 526008
      [tmricht@m83lp54 perf]$
      
      There is no error about failed memory allocation and the TUI interface
      shows all entries.
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarHendrik Brueckner <brueckner@linux.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/90cb5607-3e12-5167-682d-978eba7dafa8@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      8a07aa4e
    • Thomas Richter's avatar
      perf test 6: Fix missing kvm module load for s390 · 53fe307d
      Thomas Richter authored
      Command
      
         # perf test -Fv 6
      
      fails with error
      
         running test 100 'kvm-s390:kvm_s390_create_vm' failed to parse
          event 'kvm-s390:kvm_s390_create_vm', err -1, str 'unknown tracepoint'
          event syntax error: 'kvm-s390:kvm_s390_create_vm'
                               \___ unknown tracepoint
      
      when the kvm module is not loaded or not built in.
      
      Fix this by adding a valid function which tests if the module
      is loaded. Loaded modules (or builtin KVM support) have a
      directory named
        /sys/kernel/debug/tracing/events/kvm-s390
      for this tracepoint.
      
      Check for existence of this directory.
      Signed-off-by: default avatarThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Link: http://lkml.kernel.org/r/20190604053504.43073-1-tmricht@linux.ibm.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      53fe307d
    • Adrian Hunter's avatar
      perf time-utils: Add support for multiple explicit time intervals · a77a05e2
      Adrian Hunter authored
      Currently only a single explicit time range is accepted. Add support for
      multiple ranges separated by spaces, which requires the string to be
      quoted. Update the time utils test accordingly.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lkml.kernel.org/r/20190604130017.31207-20-adrian.hunter@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      a77a05e2
    • Adrian Hunter's avatar
      perf tests: Add a test for time-utils · e39a12cb
      Adrian Hunter authored
      Test time ranges work as expected.
      
      Committer testing:
      
        $ perf test "time utils"
        59: time utils                                            : Ok
        $ perf test -v "time utils"
        59: time utils                                            :
        --- start ---
        test child forked, pid 31711
      
        parse_nsec_time("0")
        0
      
        parse_nsec_time("1")
        1000000000
      
        parse_nsec_time("0.000000001")
        1
      
        parse_nsec_time("1.000000001")
        1000000001
      
        parse_nsec_time("123456.123456")
        123456123456000
      
        parse_nsec_time("1234567.123456789")
        1234567123456789
      
        parse_nsec_time("18446744073.709551615")
        18446744073709551615
      
        perf_time__parse_str("1234567.123456789,1234567.123456789")
        start time 1234567123456789, end time 1234567123456789
      
        perf_time__parse_str("1234567.123456789,1234567.123456790")
        start time 1234567123456789, end time 1234567123456790
      
        perf_time__parse_str("1234567.123456789,")
        start time 1234567123456789, end time 0
      
        perf_time__parse_str(",1234567.123456789")
        start time 0, end time 1234567123456789
      
        perf_time__parse_str("0,1234567.123456789")
        start time 0, end time 1234567123456789
      
        perf_time__parse_for_ranges("1234567.123456789,1234567.123456790")
        start time 1234567123456789, end time 1234567123456790
      
        perf_time__parse_for_ranges("10%/1")
        first_sample_time 7654321000000000 last_sample_time 7654321000000100
        start time 0: 7654321000000000, end time 0: 7654321000000009
      
        perf_time__parse_for_ranges("10%/2")
        first_sample_time 7654321000000000 last_sample_time 7654321000000100
        start time 0: 7654321000000010, end time 0: 7654321000000019
      
        perf_time__parse_for_ranges("10%/1,10%/2")
        first_sample_time 11223344000000000 last_sample_time 11223344000000100
        start time 0: 11223344000000000, end time 0: 11223344000000009
        start time 1: 11223344000000010, end time 1: 11223344000000019
      
        perf_time__parse_for_ranges("10%/1,10%/3,10%/10")
        first_sample_time 11223344000000000 last_sample_time 11223344000000100
        start time 0: 11223344000000000, end time 0: 11223344000000009
        start time 1: 11223344000000020, end time 1: 11223344000000029
        start time 2: 11223344000000090, end time 2: 11223344000000100
      
        test child finished with 0
        ---- end ----
        time utils: Ok
        $
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Tested-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Link: http://lkml.kernel.org/r/20190604130017.31207-19-adrian.hunter@intel.comSigned-off-by: default avatarArnaldo Carvalho de Melo <acme@redhat.com>
      e39a12cb