[GIT PULL 0/2] perf/urgent fixes for 4.12

[GIT PULL 0/2] perf/urgent fixes for 4.12

[Arnaldo Carvalho de Melo]

Hi Ingo,

	Please consider pulling,

- Arnaldo

Test results at the end of this message, as usual.

The following changes since commit 47c1ded7fef108c730b803cd386241beffcdd15c:

  Merge tag 'perf-urgent-for-mingo-4.12-20170608' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent (2017-06-09 00:41:33 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-4.12-20170613

for you to fetch changes up to 9e0c6fd15fcaea39784d1fb3e9fc573f1cf0ae60:

  perf tools: Fix build with ARCH=x86_64 (2017-06-13 16:20:37 -0300)

----------------------------------------------------------------
perf/urgent fixes:

- Fix probing of precise_ip level for default cycles event, that
  got broken recently on x86_64 when its arch code started
  considering invalid requesting precise samples when not sampling
  (i.e. when attr.sample_period == 0).

  This also fixes another problem in s/390 where the precision
  probing with sample_period == 0 returned precise_ip > 0, that
  then, when setting up the real cycles event (not probing) would
  return EOPNOTSUPP for precise_ip > 0 (as determined previously
  by probing) and sample_period > 0.

  These problems resulted in attr_precise not being set to the
  highest precision available on x86.64 when no event was specified,
  i.e. the canonical:

	perf record ./workload

  would end up using attr.precise_ip = 0. As a workaround this would
  need to be done:

	perf record -e cycles:P ./workload

  And on s/390 it would plain not work, requiring using:

        perf record -e cycles ./workload

  as a workaround.  (Arnaldo Carvalho de Melo)

- Fix perf build with ARCH=x86_64, when ARCH should be transformed
  into ARCH=x86, just like with the main kernel Makefile and
  tools/objtool's, i.e. use SRCARCH. (Jiada Wang)

Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

----------------------------------------------------------------
Arnaldo Carvalho de Melo (1):
      perf evsel: Fix probing of precise_ip level for default cycles event

Jiada Wang (1):
      perf tools: Fix build with ARCH=x86_64

 tools/perf/Makefile.config   | 38 +++++++++++++++++++-------------------
 tools/perf/Makefile.perf     |  2 +-
 tools/perf/arch/Build        |  2 +-
 tools/perf/pmu-events/Build  |  4 ++--
 tools/perf/tests/Build       |  2 +-
 tools/perf/tests/task-exit.c |  2 +-
 tools/perf/util/evsel.c      |  5 +++++
 tools/perf/util/header.c     |  2 +-
 8 files changed, 31 insertions(+), 26 deletions(-)

Test results:

The first ones are container (docker) based builds of tools/perf with and
without libelf support, objtool where it is supported and samples/bpf/, ditto.
Where clang is available, it is also used to build perf with/without libelf.

Several are cross builds, the ones with -x-ARCH, and the android one, and those
may not have all the features built, due to lack of multi-arch devel packages,
available and being used so far on just a few, like
debian:experimental-x-{arm64,mipsel}.

The 'perf test' one will perform a variety of tests exercising
tools/perf/util/, tools/lib/{bpf,traceevent,etc}, as well as run perf commands
with a variety of command line event specifications to then intercept the
sys_perf_event syscall to check that the perf_event_attr fields are set up as
expected, among a variety of other unit tests.

Then there is the 'make -C tools/perf build-test' ones, that build tools/perf/
with a variety of feature sets, exercising the build with an incomplete set of
features as well as with a complete one. It is planned to have it run on each
of the containers mentioned above, using some container orchestration
infrastructure. Get in contact if interested in helping having this in place.

  # dm
   1 alpine:3.4: Ok
   2 alpine:3.5: Ok
   3 alpine:3.6: Ok
   4 alpine:edge: Ok
   5 android-ndk:r12b-arm: Ok
   6 archlinux:latest: Ok
   7 centos:5: Ok
   8 centos:6: Ok
   9 centos:7: Ok
  10 debian:7: Ok
  11 debian:8: Ok
  12 debian:9: Ok
  13 debian:experimental: Ok
  14 debian:experimental-x-arm64: Ok
  15 debian:experimental-x-mips: Ok
  16 debian:experimental-x-mips64: Ok
  17 debian:experimental-x-mipsel: Ok
  18 fedora:20: Ok
  19 fedora:21: Ok
  20 fedora:22: Ok
  21 fedora:23: Ok
  22 fedora:24: Ok
  23 fedora:24-x-ARC-uClibc: Ok
  24 fedora:25: Ok
  25 fedora:rawhide: Ok
  26 mageia:5: Ok
  27 opensuse:13.2: Ok
  28 opensuse:42.1: Ok
  29 opensuse:tumbleweed: Ok
  30 ubuntu:12.04.5: Ok
  31 ubuntu:14.04.4: Ok
  32 ubuntu:14.04.4-x-linaro-arm64: Ok
  33 ubuntu:15.10: Ok
  34 ubuntu:16.04: Ok
  35 ubuntu:16.04-x-arm: Ok
  36 ubuntu:16.04-x-arm64: Ok
  37 ubuntu:16.04-x-powerpc: Ok
  38 ubuntu:16.04-x-powerpc64: Ok
  39 ubuntu:16.04-x-powerpc64el: Ok
  40 ubuntu:16.04-x-s390: Ok
  41 ubuntu:16.10: Ok
  42 ubuntu:17.04: Ok
  #

  # uname -a
  Linux jouet 4.12.0-rc4+ #1 SMP Fri Jun 9 12:59:23 -03 2017 x86_64 x86_64 x86_64 GNU/Linux
  # perf test
   1: vmlinux symtab matches kallsyms            : Ok
   2: Detect openat syscall event                : Ok
   3: Detect openat syscall event on all cpus    : Ok
   4: Read samples using the mmap interface      : Ok
   5: Parse event definition strings             : Ok
   6: Simple expression parser                   : Ok
   7: PERF_RECORD_* events & perf_sample fields  : Ok
   8: Parse perf pmu format                      : Ok
   9: DSO data read                              : Ok
  10: DSO data cache                             : Ok
  11: DSO data reopen                            : Ok
  12: Roundtrip evsel->name                      : Ok
  13: Parse sched tracepoints fields             : Ok
  14: syscalls:sys_enter_openat event fields     : Ok
  15: Setup struct perf_event_attr               : Ok
  16: Match and link multiple hists              : Ok
  17: 'import perf' in python                    : Ok
  18: Breakpoint overflow signal handler         : Ok
  19: Breakpoint overflow sampling               : Ok
  20: Number of exit events of a simple workload : Ok
  21: Software clock events period values        : Ok
  22: Object code reading                        : Ok
  23: Sample parsing                             : Ok
  24: Use a dummy software event to keep tracking: Ok
  25: Parse with no sample_id_all bit set        : Ok
  26: Filter hist entries                        : Ok
  27: Lookup mmap thread                         : Ok
  28: Share thread mg                            : Ok
  29: Sort output of hist entries                : Ok
  30: Cumulate child hist entries                : Ok
  31: Track with sched_switch                    : Ok
  32: Filter fds with revents mask in a fdarray  : Ok
  33: Add fd to a fdarray, making it autogrow    : Ok
  34: kmod_path__parse                           : Ok
  35: Thread map                                 : Ok
  36: LLVM search and compile                    :
  36.1: Basic BPF llvm compile                    : Ok
  36.2: kbuild searching                          : Ok
  36.3: Compile source for BPF prologue generation: Ok
  36.4: Compile source for BPF relocation         : Ok
  37: Session topology                           : Ok
  38: BPF filter                                 :
  38.1: Basic BPF filtering                      : Ok
  38.2: BPF pinning                              : Ok
  38.3: BPF prologue generation                  : Ok
  38.4: BPF relocation checker                   : Ok
  39: Synthesize thread map                      : Ok
  40: Remove thread map                          : Ok
  41: Synthesize cpu map                         : Ok
  42: Synthesize stat config                     : Ok
  43: Synthesize stat                            : Ok
  44: Synthesize stat round                      : Ok
  45: Synthesize attr update                     : Ok
  46: Event times                                : Ok
  47: Read backward ring buffer                  : Ok
  48: Print cpu map                              : Ok
  49: Probe SDT events                           : Ok
  50: is_printable_array                         : Ok
  51: Print bitmap                               : Ok
  52: perf hooks                                 : Ok
  53: builtin clang support                      : Skip (not compiled in)
  54: unit_number__scnprintf                     : Ok
  55: x86 rdpmc                                  : Ok
  56: Convert perf time to TSC                   : Ok
  57: DWARF unwind                               : Ok
  58: x86 instruction decoder - new instructions : Ok
  59: Intel cqm nmi context read                 : Skip
  #

  $ make -C tools/perf build-test
  make: Entering directory '/home/acme/git/linux/tools/perf'
  - tarpkg: ./tests/perf-targz-src-pkg .
            make_no_libaudit_O: make NO_LIBAUDIT=1
                make_minimal_O: make NO_LIBPERL=1 NO_LIBPYTHON=1 NO_NEWT=1 NO_GTK2=1 NO_DEMANGLE=1 NO_LIBELF=1 NO_LIBUNWIND=1 NO_BACKTRACE=1 NO_LIBNUMA=1 NO_LIBAUDIT=1 NO_LIBBIONIC=1 NO_LIBDW_DWARF_UNWIND=1 NO_AUXTRACE=1 NO_LIBBPF=1 NO_LIBCRYPTO=1 NO_SDT=1 NO_JVMTI=1
         make_with_clangllvm_O: make LIBCLANGLLVM=1
              make_clean_all_O: make clean all
               make_no_slang_O: make NO_SLANG=1
                   make_help_O: make help
   make_install_prefix_slash_O: make install prefix=/tmp/krava/
           make_no_libunwind_O: make NO_LIBUNWIND=1
             make_no_scripts_O: make NO_LIBPYTHON=1 NO_LIBPERL=1
        make_with_babeltrace_O: make LIBBABELTRACE=1
                make_install_O: make install
              make_no_libelf_O: make NO_LIBELF=1
                    make_doc_O: make doc
  make_no_libdw_dwarf_unwind_O: make NO_LIBDW_DWARF_UNWIND=1
                   make_tags_O: make tags
             make_no_libnuma_O: make NO_LIBNUMA=1
            make_no_demangle_O: make NO_DEMANGLE=1
            make_no_auxtrace_O: make NO_AUXTRACE=1
              make_no_libbpf_O: make NO_LIBBPF=1
           make_no_libbionic_O: make NO_LIBBIONIC=1
           make_no_libpython_O: make NO_LIBPYTHON=1
             make_no_libperl_O: make NO_LIBPERL=1
       make_util_pmu_bison_o_O: make util/pmu-bison.o
                make_no_gtk2_O: make NO_GTK2=1
            make_install_bin_O: make install-bin
                  make_no_ui_O: make NO_NEWT=1 NO_SLANG=1 NO_GTK2=1
                  make_debug_O: make DEBUG=1
             make_util_map_o_O: make util/map.o
         make_install_prefix_O: make install prefix=/tmp/krava
                   make_pure_O: make
           make_no_backtrace_O: make NO_BACKTRACE=1
  cd . && make FEATURE_DUMP_COPY=/home/acme/git/linux/tools/perf/BUILD_TEST_FEATURE_DUMP_STATIC LDFLAGS='-static' feature-dump
                 make_static_O: make LDFLAGS=-static
                 make_perf_o_O: make perf.o
                make_no_newt_O: make NO_NEWT=1
  OK
  $

[PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo <acme@redhat.com>

Since commit 18e7a45af91a ("perf/x86: Reject non sampling events with
precise_ip") returns -EINVAL for sys_perf_event_open() with an attribute
with (attr.precise_ip > 0 && attr.sample_period == 0), just like is done
in the routine used to probe the max precise level when no events were
passed to 'perf record' or 'perf top', i.e.:

	perf_evsel__new_cycles()
		perf_event_attr__set_max_precise_ip()

The x86 code, in x86_pmu_hw_config(), which is called all the way from
sys_perf_event_open() did, starting with the aforementioned commit:

                /* There's no sense in having PEBS for non sampling events: */
                if (!is_sampling_event(event))
                        return -EINVAL;

Which makes it fail for cycles:ppp, cycles:pp and cycles:p, always using
just the non precise cycles variant.

To make sure that this is the case, I tested it, before this patch,
with:

  # perf probe -L x86_pmu_hw_config
  <x86_pmu_hw_config@/home/acme/git/linux/arch/x86/events/core.c:0>
        0  int x86_pmu_hw_config(struct perf_event *event)
        1  {
        2         if (event->attr.precise_ip) {
<SNIP>
       17                 if (event->attr.precise_ip > precise)
       18                         return -EOPNOTSUPP;

                          /* There's no sense in having PEBS for non sampling events: */
       21                 if (!is_sampling_event(event))
       22                         return -EINVAL;
                  }
<SNIP>
  # perf probe x86_pmu_hw_config:22
  Added new events:
    probe:x86_pmu_hw_config (on x86_pmu_hw_config:22)
    probe:x86_pmu_hw_config_1 (on x86_pmu_hw_config:22)

  You can now use it in all perf tools, such as:

        perf record -e probe:x86_pmu_hw_config_1 -aR sleep 1

  # perf trace -e perf_event_open,probe:x86_pmu_hwconfig*/max-stack=16/ perf record usleep 1
     0.000 ( 0.015 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8ba110, cpu: -1, group_fd: -1      ) ...
     0.015 (         ): probe:x86_pmu_hw_config:(ffffffff9c0065e1))
                                       x86_pmu_hw_config ([kernel.kallsyms])
                                       hsw_hw_config ([kernel.kallsyms])
                                       x86_pmu_event_init ([kernel.kallsyms])
                                       perf_try_init_event ([kernel.kallsyms])
                                       perf_event_alloc ([kernel.kallsyms])
                                       SYSC_perf_event_open ([kernel.kallsyms])
                                       sys_perf_event_open ([kernel.kallsyms])
                                       do_syscall_64 ([kernel.kallsyms])
                                       return_from_SYSCALL_64 ([kernel.kallsyms])
                                       syscall (/usr/lib64/libc-2.24.so)
                                       perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
                                       perf_evsel__new_cycles (/home/acme/bin/perf)
                                       perf_evlist__add_default (/home/acme/bin/perf)
                                       cmd_record (/home/acme/bin/perf)
                                       run_builtin (/home/acme/bin/perf)
                                       handle_internal_command (/home/acme/bin/perf)
     0.000 ( 0.021 ms): perf/4150  ... [continued]: perf_event_open()) = -1 EINVAL Invalid argument
     0.023 ( 0.002 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8ba110, cpu: -1, group_fd: -1      ) ...
     0.025 (         ): probe:x86_pmu_hw_config:(ffffffff9c0065e1))
                                       x86_pmu_hw_config ([kernel.kallsyms])
                                       hsw_hw_config ([kernel.kallsyms])
                                       x86_pmu_event_init ([kernel.kallsyms])
                                       perf_try_init_event ([kernel.kallsyms])
                                       perf_event_alloc ([kernel.kallsyms])
                                       SYSC_perf_event_open ([kernel.kallsyms])
                                       sys_perf_event_open ([kernel.kallsyms])
                                       do_syscall_64 ([kernel.kallsyms])
                                       return_from_SYSCALL_64 ([kernel.kallsyms])
                                       syscall (/usr/lib64/libc-2.24.so)
                                       perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
                                       perf_evsel__new_cycles (/home/acme/bin/perf)
                                       perf_evlist__add_default (/home/acme/bin/perf)
                                       cmd_record (/home/acme/bin/perf)
                                       run_builtin (/home/acme/bin/perf)
                                       handle_internal_command (/home/acme/bin/perf)
     0.023 ( 0.004 ms): perf/4150  ... [continued]: perf_event_open()) = -1 EINVAL Invalid argument
     0.028 ( 0.002 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8ba110, cpu: -1, group_fd: -1      ) ...
     0.030 (         ): probe:x86_pmu_hw_config:(ffffffff9c0065e1))
                                       x86_pmu_hw_config ([kernel.kallsyms])
                                       hsw_hw_config ([kernel.kallsyms])
                                       x86_pmu_event_init ([kernel.kallsyms])
                                       perf_try_init_event ([kernel.kallsyms])
                                       perf_event_alloc ([kernel.kallsyms])
                                       SYSC_perf_event_open ([kernel.kallsyms])
                                       sys_perf_event_open ([kernel.kallsyms])
                                       do_syscall_64 ([kernel.kallsyms])
                                       return_from_SYSCALL_64 ([kernel.kallsyms])
                                       syscall (/usr/lib64/libc-2.24.so)
                                       perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
                                       perf_evsel__new_cycles (/home/acme/bin/perf)
                                       perf_evlist__add_default (/home/acme/bin/perf)
                                       cmd_record (/home/acme/bin/perf)
                                       run_builtin (/home/acme/bin/perf)
                                       handle_internal_command (/home/acme/bin/perf)
     0.028 ( 0.004 ms): perf/4150  ... [continued]: perf_event_open()) = -1 EINVAL Invalid argument
    41.018 ( 0.012 ms): perf/4150 perf_event_open(attr_uptr: 0x7ffebc8b5dd0, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
    41.065 ( 0.011 ms): perf/4150 perf_event_open(attr_uptr: 0x3c7db78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
    41.080 ( 0.006 ms): perf/4150 perf_event_open(attr_uptr: 0x3c7db78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
    41.103 ( 0.010 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), group_fd: -1, flags: FD_CLOEXEC) = 4
    41.115 ( 0.006 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), cpu: 1, group_fd: -1, flags: FD_CLOEXEC) = 5
    41.122 ( 0.004 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), cpu: 2, group_fd: -1, flags: FD_CLOEXEC) = 6
    41.128 ( 0.008 ms): perf/4150 perf_event_open(attr_uptr: 0x3c4e748, pid: 4151 (perf), cpu: 3, group_fd: -1, flags: FD_CLOEXEC) = 8
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.017 MB perf.data (2 samples) ]
  #

I.e. that return -EINVAL in x86_pmu_hw_config() is hit three times.

So fix it by just setting attr.sample_period

Now, after this patch:

  # perf trace --max-stack=2 -e perf_event_open,probe:x86_pmu_hw_config* perf record usleep 1
  [ perf record: Woken up 1 times to write data ]
     0.000 ( 0.017 ms): perf/8469 perf_event_open(attr_uptr: 0x7ffe36c27d10, pid: -1, cpu: 3, group_fd: -1, flags: FD_CLOEXEC) = 4
                                       syscall (/usr/lib64/libc-2.24.so)
                                       perf_event_open_cloexec_flag (/home/acme/bin/perf)
     0.050 ( 0.031 ms): perf/8469 perf_event_open(attr_uptr: 0x24ebb78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
                                       syscall (/usr/lib64/libc-2.24.so)
                                       perf_evlist__config (/home/acme/bin/perf)
     0.092 ( 0.040 ms): perf/8469 perf_event_open(attr_uptr: 0x24ebb78, pid: -1, group_fd: -1, flags: FD_CLOEXEC) = 4
                                       syscall (/usr/lib64/libc-2.24.so)
                                       perf_evlist__config (/home/acme/bin/perf)
     0.143 ( 0.007 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, cpu: -1, group_fd: -1           ) = 4
                                       syscall (/usr/lib64/libc-2.24.so)
                                       perf_event_attr__set_max_precise_ip (/home/acme/bin/perf)
     0.161 ( 0.007 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), group_fd: -1, flags: FD_CLOEXEC) = 4
                                       syscall (/usr/lib64/libc-2.24.so)
                                       perf_evsel__open (/home/acme/bin/perf)
     0.171 ( 0.005 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), cpu: 1, group_fd: -1, flags: FD_CLOEXEC) = 5
                                       syscall (/usr/lib64/libc-2.24.so)
                                       perf_evsel__open (/home/acme/bin/perf)
     0.180 ( 0.007 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), cpu: 2, group_fd: -1, flags: FD_CLOEXEC) = 6
                                       syscall (/usr/lib64/libc-2.24.so)
                                       perf_evsel__open (/home/acme/bin/perf)
     0.190 ( 0.005 ms): perf/8469 perf_event_open(attr_uptr: 0x24bc748, pid: 8470 (perf), cpu: 3, group_fd: -1, flags: FD_CLOEXEC) = 8
                                       syscall (/usr/lib64/libc-2.24.so)
                                       perf_evsel__open (/home/acme/bin/perf)
  [ perf record: Captured and wrote 0.017 MB perf.data (7 samples) ]
  #

The probe one called from perf_event_attr__set_max_precise_ip() works
the first time, with attr.precise_ip = 3, wit hthe next ones being the
per cpu ones for the cycles:ppp event.

And here is the text from a report and alternative proposed patch by
Thomas-Mich Richter:

 ---

On s390 the counter and sampling facility do not support a precise IP
skid level and sometimes returns EOPNOTSUPP when structure member
precise_ip in struct perf_event_attr is not set to zero.

On s390 commnd 'perf record -- true' fails with error EOPNOTSUPP.  This
happens only when no events are specified on command line.

The functions called are
...
  --> perf_evlist__add_default
      --> perf_evsel__new_cycles
          --> perf_event_attr__set_max_precise_ip

The last function determines the value of structure member precise_ip by
invoking the perf_event_open() system call and checking the return code.
The first successful open is the value for precise_ip.

However the value is determined without setting member sample_period and
indicates no sampling.

On s390 the counter facility and sampling facility are different.  The
above procedure determines a precise_ip value of 3 using the counter
facility. Later it uses the sampling facility with a value of 3 and
fails with EOPNOTSUPP.

 ---

v2: Older compilers (e.g. gcc 4.4.7) don't support referencing members
    of unnamed union members in the container struct initialization, so
    move from:

	struct perf_event_attr attr = {
		...
		.sample_period = 1,
	};

to right after it as:

	struct perf_event_attr attr = {
		...
	};

	attr.sample_period = 1;

Reported-and-Acked-by: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Acked-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa@redhat.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 18e7a45af91a ("perf/x86: Reject non sampling events with precise_ip")
Link: http://lkml.kernel.org/n/tip-maqwgwavguzks5i3q8g99azd@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/tests/task-exit.c | 2 +-
 tools/perf/util/evsel.c      | 5 +++++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/task-exit.c b/tools/perf/tests/task-exit.c
index 32873ec91a4e..cf00ebad2ef5 100644
--- a/tools/perf/tests/task-exit.c
+++ b/tools/perf/tests/task-exit.c
@@ -83,7 +83,7 @@ int test__task_exit(int subtest __maybe_unused)
 
 	evsel = perf_evlist__first(evlist);
 	evsel->attr.task = 1;
-	evsel->attr.sample_freq = 0;
+	evsel->attr.sample_freq = 1;
 	evsel->attr.inherit = 0;
 	evsel->attr.watermark = 0;
 	evsel->attr.wakeup_events = 1;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index e4f7902d5afa..a7ce529ca36c 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -273,6 +273,11 @@ struct perf_evsel *perf_evsel__new_cycles(void)
 	struct perf_evsel *evsel;
 
 	event_attr_init(&attr);
+	/*
+	 * Unnamed union member, not supported as struct member named
+	 * initializer in older compilers such as gcc 4.4.7
+	 */
+	attr.sample_period = 1;
 
 	perf_event_attr__set_max_precise_ip(&attr);
 
-- 
2.9.4

[PATCH 2/2] perf tools: Fix build with ARCH=x86_64

[Arnaldo Carvalho de Melo]

From: Jiada Wang <jiada_wang@mentor.com>

With commit: 0a943cb10ce78 (tools build: Add HOSTARCH Makefile variable)
when building for ARCH=x86_64, ARCH=x86_64 is passed to perf instead of
ARCH=x86, so the perf build process searchs header files from
tools/arch/x86_64/include, which doesn't exist.

The following build failure is seen:

  In file included from util/event.c:2:0:
    tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No such file or directory
    compilation terminated.

Fix this issue by using SRCARCH instead of ARCH in perf, just like the
main kernel Makefile and tools/objtool's.

Signed-off-by: Jiada Wang <jiada_wang@mentor.com>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: Jan Stancek <jstancek@redhat.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
Cc: Rui Teng <rui.teng@linux.vnet.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: 0a943cb10ce7 ("tools build: Add HOSTARCH Makefile variable")
Link: http://lkml.kernel.org/r/1491793357-14977-2-git-send-email-jiada_wang@mentor.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/perf/Makefile.config  | 38 +++++++++++++++++++-------------------
 tools/perf/Makefile.perf    |  2 +-
 tools/perf/arch/Build       |  2 +-
 tools/perf/pmu-events/Build |  4 ++--
 tools/perf/tests/Build      |  2 +-
 tools/perf/util/header.c    |  2 +-
 6 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 8354d04b392f..1f4fbc9a3292 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -19,18 +19,18 @@ CFLAGS := $(EXTRA_CFLAGS) $(EXTRA_WARNINGS)
 
 include $(srctree)/tools/scripts/Makefile.arch
 
-$(call detected_var,ARCH)
+$(call detected_var,SRCARCH)
 
 NO_PERF_REGS := 1
 
 # Additional ARCH settings for ppc
-ifeq ($(ARCH),powerpc)
+ifeq ($(SRCARCH),powerpc)
   NO_PERF_REGS := 0
   LIBUNWIND_LIBS := -lunwind -lunwind-ppc64
 endif
 
 # Additional ARCH settings for x86
-ifeq ($(ARCH),x86)
+ifeq ($(SRCARCH),x86)
   $(call detected,CONFIG_X86)
   ifeq (${IS_64_BIT}, 1)
     CFLAGS += -DHAVE_ARCH_X86_64_SUPPORT -DHAVE_SYSCALL_TABLE -I$(OUTPUT)arch/x86/include/generated
@@ -43,12 +43,12 @@ ifeq ($(ARCH),x86)
   NO_PERF_REGS := 0
 endif
 
-ifeq ($(ARCH),arm)
+ifeq ($(SRCARCH),arm)
   NO_PERF_REGS := 0
   LIBUNWIND_LIBS = -lunwind -lunwind-arm
 endif
 
-ifeq ($(ARCH),arm64)
+ifeq ($(SRCARCH),arm64)
   NO_PERF_REGS := 0
   LIBUNWIND_LIBS = -lunwind -lunwind-aarch64
 endif
@@ -61,7 +61,7 @@ endif
 # Disable it on all other architectures in case libdw unwind
 # support is detected in system. Add supported architectures
 # to the check.
-ifneq ($(ARCH),$(filter $(ARCH),x86 arm))
+ifneq ($(SRCARCH),$(filter $(SRCARCH),x86 arm))
   NO_LIBDW_DWARF_UNWIND := 1
 endif
 
@@ -115,9 +115,9 @@ endif
 FEATURE_CHECK_CFLAGS-libbabeltrace := $(LIBBABELTRACE_CFLAGS)
 FEATURE_CHECK_LDFLAGS-libbabeltrace := $(LIBBABELTRACE_LDFLAGS) -lbabeltrace-ctf
 
-FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(ARCH)/include/uapi -I$(srctree)/tools/include/uapi
+FEATURE_CHECK_CFLAGS-bpf = -I. -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(SRCARCH)/include/uapi -I$(srctree)/tools/include/uapi
 # include ARCH specific config
--include $(src-perf)/arch/$(ARCH)/Makefile
+-include $(src-perf)/arch/$(SRCARCH)/Makefile
 
 ifdef PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET
   CFLAGS += -DHAVE_ARCH_REGS_QUERY_REGISTER_OFFSET
@@ -228,12 +228,12 @@ ifeq ($(DEBUG),0)
 endif
 
 INC_FLAGS += -I$(src-perf)/util/include
-INC_FLAGS += -I$(src-perf)/arch/$(ARCH)/include
+INC_FLAGS += -I$(src-perf)/arch/$(SRCARCH)/include
 INC_FLAGS += -I$(srctree)/tools/include/uapi
 INC_FLAGS += -I$(srctree)/tools/include/
-INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/uapi
-INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/include/
-INC_FLAGS += -I$(srctree)/tools/arch/$(ARCH)/
+INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/include/uapi
+INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/include/
+INC_FLAGS += -I$(srctree)/tools/arch/$(SRCARCH)/
 
 # $(obj-perf)      for generated common-cmds.h
 # $(obj-perf)/util for generated bison/flex headers
@@ -355,7 +355,7 @@ ifndef NO_LIBELF
 
   ifndef NO_DWARF
     ifeq ($(origin PERF_HAVE_DWARF_REGS), undefined)
-      msg := $(warning DWARF register mappings have not been defined for architecture $(ARCH), DWARF support disabled);
+      msg := $(warning DWARF register mappings have not been defined for architecture $(SRCARCH), DWARF support disabled);
       NO_DWARF := 1
     else
       CFLAGS += -DHAVE_DWARF_SUPPORT $(LIBDW_CFLAGS)
@@ -380,7 +380,7 @@ ifndef NO_LIBELF
         CFLAGS += -DHAVE_BPF_PROLOGUE
         $(call detected,CONFIG_BPF_PROLOGUE)
       else
-        msg := $(warning BPF prologue is not supported by architecture $(ARCH), missing regs_query_register_offset());
+        msg := $(warning BPF prologue is not supported by architecture $(SRCARCH), missing regs_query_register_offset());
       endif
     else
       msg := $(warning DWARF support is off, BPF prologue is disabled);
@@ -406,7 +406,7 @@ ifdef PERF_HAVE_JITDUMP
   endif
 endif
 
-ifeq ($(ARCH),powerpc)
+ifeq ($(SRCARCH),powerpc)
   ifndef NO_DWARF
     CFLAGS += -DHAVE_SKIP_CALLCHAIN_IDX
   endif
@@ -487,7 +487,7 @@ else
 endif
 
 ifndef NO_LOCAL_LIBUNWIND
-  ifeq ($(ARCH),$(filter $(ARCH),arm arm64))
+  ifeq ($(SRCARCH),$(filter $(SRCARCH),arm arm64))
     $(call feature_check,libunwind-debug-frame)
     ifneq ($(feature-libunwind-debug-frame), 1)
       msg := $(warning No debug_frame support found in libunwind);
@@ -740,7 +740,7 @@ ifeq (${IS_64_BIT}, 1)
       NO_PERF_READ_VDSO32 := 1
     endif
   endif
-  ifneq ($(ARCH), x86)
+  ifneq ($(SRCARCH), x86)
     NO_PERF_READ_VDSOX32 := 1
   endif
   ifndef NO_PERF_READ_VDSOX32
@@ -769,7 +769,7 @@ ifdef LIBBABELTRACE
 endif
 
 ifndef NO_AUXTRACE
-  ifeq ($(ARCH),x86)
+  ifeq ($(SRCARCH),x86)
     ifeq ($(feature-get_cpuid), 0)
       msg := $(warning Your gcc lacks the __get_cpuid() builtin, disables support for auxtrace/Intel PT, please install a newer gcc);
       NO_AUXTRACE := 1
@@ -872,7 +872,7 @@ sysconfdir = $(prefix)/etc
 ETC_PERFCONFIG = etc/perfconfig
 endif
 ifndef lib
-ifeq ($(ARCH)$(IS_64_BIT), x861)
+ifeq ($(SRCARCH)$(IS_64_BIT), x861)
 lib = lib64
 else
 lib = lib
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 79fe31f20a17..5008f51a08a2 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -226,7 +226,7 @@ endif
 
 ifeq ($(config),0)
 include $(srctree)/tools/scripts/Makefile.arch
--include arch/$(ARCH)/Makefile
+-include arch/$(SRCARCH)/Makefile
 endif
 
 # The FEATURE_DUMP_EXPORT holds location of the actual
diff --git a/tools/perf/arch/Build b/tools/perf/arch/Build
index 109eb75cf7de..d9b6af837c7d 100644
--- a/tools/perf/arch/Build
+++ b/tools/perf/arch/Build
@@ -1,2 +1,2 @@
 libperf-y += common.o
-libperf-y += $(ARCH)/
+libperf-y += $(SRCARCH)/
diff --git a/tools/perf/pmu-events/Build b/tools/perf/pmu-events/Build
index 9213a1273697..999a4e878162 100644
--- a/tools/perf/pmu-events/Build
+++ b/tools/perf/pmu-events/Build
@@ -2,7 +2,7 @@ hostprogs := jevents
 
 jevents-y	+= json.o jsmn.o jevents.o
 pmu-events-y	+= pmu-events.o
-JDIR		=  pmu-events/arch/$(ARCH)
+JDIR		=  pmu-events/arch/$(SRCARCH)
 JSON		=  $(shell [ -d $(JDIR) ] &&				\
 			find $(JDIR) -name '*.json' -o -name 'mapfile.csv')
 #
@@ -10,4 +10,4 @@ JSON		=  $(shell [ -d $(JDIR) ] &&				\
 # directory and create tables in pmu-events.c.
 #
 $(OUTPUT)pmu-events/pmu-events.c: $(JSON) $(JEVENTS)
-	$(Q)$(call echo-cmd,gen)$(JEVENTS) $(ARCH) pmu-events/arch $(OUTPUT)pmu-events/pmu-events.c $(V)
+	$(Q)$(call echo-cmd,gen)$(JEVENTS) $(SRCARCH) pmu-events/arch $(OUTPUT)pmu-events/pmu-events.c $(V)
diff --git a/tools/perf/tests/Build b/tools/perf/tests/Build
index af58ebc243ef..84222bdb8689 100644
--- a/tools/perf/tests/Build
+++ b/tools/perf/tests/Build
@@ -75,7 +75,7 @@ $(OUTPUT)tests/llvm-src-relocation.c: tests/bpf-script-test-relocation.c tests/B
 	$(Q)sed -e 's/"/\\"/g' -e 's/\(.*\)/"\1\\n"/g' $< >> $@
 	$(Q)echo ';' >> $@
 
-ifeq ($(ARCH),$(filter $(ARCH),x86 arm arm64 powerpc))
+ifeq ($(SRCARCH),$(filter $(SRCARCH),x86 arm arm64 powerpc))
 perf-$(CONFIG_DWARF_UNWIND) += dwarf-unwind.o
 endif
 
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 5cac8d5e009a..b5baff3007bb 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -841,7 +841,7 @@ static int write_group_desc(int fd, struct perf_header *h __maybe_unused,
 
 /*
  * default get_cpuid(): nothing gets recorded
- * actual implementation must be in arch/$(ARCH)/util/header.c
+ * actual implementation must be in arch/$(SRCARCH)/util/header.c
  */
 int __weak get_cpuid(char *buffer __maybe_unused, size_t sz __maybe_unused)
 {
-- 
2.9.4

Re: [GIT PULL 0/2] perf/urgent fixes for 4.12

[Ingo Molnar]

* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Hi Ingo,
> 
> 	Please consider pulling,
> 
> - Arnaldo
> 
> Test results at the end of this message, as usual.
> 
> The following changes since commit 47c1ded7fef108c730b803cd386241beffcdd15c:
> 
>   Merge tag 'perf-urgent-for-mingo-4.12-20170608' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent (2017-06-09 00:41:33 +0200)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-4.12-20170613
> 
> for you to fetch changes up to 9e0c6fd15fcaea39784d1fb3e9fc573f1cf0ae60:
> 
>   perf tools: Fix build with ARCH=x86_64 (2017-06-13 16:20:37 -0300)
> 
> ----------------------------------------------------------------
> perf/urgent fixes:
> 
> - Fix probing of precise_ip level for default cycles event, that
>   got broken recently on x86_64 when its arch code started
>   considering invalid requesting precise samples when not sampling
>   (i.e. when attr.sample_period == 0).
> 
>   This also fixes another problem in s/390 where the precision
>   probing with sample_period == 0 returned precise_ip > 0, that
>   then, when setting up the real cycles event (not probing) would
>   return EOPNOTSUPP for precise_ip > 0 (as determined previously
>   by probing) and sample_period > 0.
> 
>   These problems resulted in attr_precise not being set to the
>   highest precision available on x86.64 when no event was specified,
>   i.e. the canonical:
> 
> 	perf record ./workload
> 
>   would end up using attr.precise_ip = 0. As a workaround this would
>   need to be done:
> 
> 	perf record -e cycles:P ./workload
> 
>   And on s/390 it would plain not work, requiring using:
> 
>         perf record -e cycles ./workload
> 
>   as a workaround.  (Arnaldo Carvalho de Melo)
> 
> - Fix perf build with ARCH=x86_64, when ARCH should be transformed
>   into ARCH=x86, just like with the main kernel Makefile and
>   tools/objtool's, i.e. use SRCARCH. (Jiada Wang)
> 
> Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> 
> ----------------------------------------------------------------
> Arnaldo Carvalho de Melo (1):
>       perf evsel: Fix probing of precise_ip level for default cycles event
> 
> Jiada Wang (1):
>       perf tools: Fix build with ARCH=x86_64
> 
>  tools/perf/Makefile.config   | 38 +++++++++++++++++++-------------------
>  tools/perf/Makefile.perf     |  2 +-
>  tools/perf/arch/Build        |  2 +-
>  tools/perf/pmu-events/Build  |  4 ++--
>  tools/perf/tests/Build       |  2 +-
>  tools/perf/tests/task-exit.c |  2 +-
>  tools/perf/util/evsel.c      |  5 +++++
>  tools/perf/util/header.c     |  2 +-
>  8 files changed, 31 insertions(+), 26 deletions(-)

Pulled, thanks a lot Arnaldo!

	Ingo

Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Ingo Molnar]

* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

>  tools/perf/tests/task-exit.c | 2 +-
>  tools/perf/util/evsel.c      | 5 +++++
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/tests/task-exit.c b/tools/perf/tests/task-exit.c
> index 32873ec91a4e..cf00ebad2ef5 100644
> --- a/tools/perf/tests/task-exit.c
> +++ b/tools/perf/tests/task-exit.c
> @@ -83,7 +83,7 @@ int test__task_exit(int subtest __maybe_unused)
>  
>  	evsel = perf_evlist__first(evlist);
>  	evsel->attr.task = 1;
> -	evsel->attr.sample_freq = 0;
> +	evsel->attr.sample_freq = 1;
>  	evsel->attr.inherit = 0;
>  	evsel->attr.watermark = 0;
>  	evsel->attr.wakeup_events = 1;
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index e4f7902d5afa..a7ce529ca36c 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -273,6 +273,11 @@ struct perf_evsel *perf_evsel__new_cycles(void)
>  	struct perf_evsel *evsel;
>  
>  	event_attr_init(&attr);
> +	/*
> +	 * Unnamed union member, not supported as struct member named
> +	 * initializer in older compilers such as gcc 4.4.7
> +	 */
> +	attr.sample_period = 1;
>  
>  	perf_event_attr__set_max_precise_ip(&attr);

Hm, so this really broke perf for me on my main system - 'perf top' and 'perf 
report' only shows:

 triton:~/tip> perf report --stdio
 unwind: target platform=x86 is not supported
 unwind: target platform=x86 is not supported
 unwind: target platform=x86 is not supported
 unwind: target platform=x86 is not supported
 unwind: target platform=x86 is not supported
 unwind: target platform=x86 is not supported
 unwind: target platform=x86 is not supported
 unwind: target platform=x86 is not supported
 # To display the perf.data header info, please use --header/--header-only options.
 #
 #
 # Total Lost Samples: 0
 #
 # Samples: 921K of event 'cycles:ppp'
 # Event count (approx.): 921045
 #
 # Overhead  Command    Shared Object     Symbol              
 # ........  .........  ................  ....................
 #
    99.93%  hackbench  [kernel.vmlinux]  [k] native_write_msr
     0.07%  perf       [kernel.vmlinux]  [k] native_write_msr

the bisection result is unambiguous:

   7fd1d092b4337831d7ccbf3a74c07cb0b2089023 is the first bad commit

proper output would be:

 ...
 #
 # Total Lost Samples: 0
 #
 # Samples: 9K of event 'cycles'
 # Event count (approx.): 4378583062
 #
 # Overhead  Command    Shared Object     Symbol                                 
 # ........  .........  ................  .......................................
 #
     4.32%  hackbench  [kernel.vmlinux]  [k] copy_user_enhanced_fast_string
     4.02%  hackbench  [kernel.vmlinux]  [k] unix_stream_read_generic
     3.75%  hackbench  [kernel.vmlinux]  [k] filemap_map_pages
     3.06%  hackbench  [kernel.vmlinux]  [k] __check_object_size
     2.44%  hackbench  [kernel.vmlinux]  [k] _raw_spin_lock_irqsave
     2.32%  hackbench  [kernel.vmlinux]  [k] native_queued_spin_lock_slowpath
     2.22%  hackbench  [kernel.vmlinux]  [k] entry_SYSENTER_compat
     1.90%  hackbench  [vdso]            [.] __vdso_gettimeofday
     1.80%  hackbench  [kernel.vmlinux]  [k] _raw_spin_lock
     1.80%  hackbench  [kernel.vmlinux]  [k] skb_set_owner_w
     1.67%  hackbench  [kernel.vmlinux]  [k] kmem_cache_free
     1.52%  hackbench  [kernel.vmlinux]  [k] skb_release_data
     1.48%  hackbench  [kernel.vmlinux]  [k] common_file_perm
     1.45%  hackbench  [kernel.vmlinux]  [k] page_fault
     1.45%  hackbench  [kernel.vmlinux]  [k] cmpxchg_double_slab.isra.62
     1.42%  hackbench  [kernel.vmlinux]  [k] new_sync_read
     1.36%  hackbench  [kernel.vmlinux]  [k] __check_heap_object

Here's the hardware details:

# ========
# captured on: Wed Jun 14 07:34:42 2017
# hostname : triton
# os release : 4.10.0-23-generic
# perf version : 4.12.rc5.g9688eb
# arch : x86_64
# nrcpus online : 12
# nrcpus avail : 12
# cpudesc : Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz
# cpuid : GenuineIntel,6,62,4
# total memory : 65917012 kB
# cmdline : /home/mingo/bin/perf record /home/mingo/hackbench 10 
# event : name = cycles:ppp, , size = 112, { sample_period, sample_freq } = 1, sample_type = IP|TID|TIME, disabled = 1, inherit = 1, mmap = 1, comm = 1, enable_on_exec = 1, task = 1,
# HEADER_CPU_TOPOLOGY info available, use -I to display
# HEADER_NUMA_TOPOLOGY info available, use -I to display
# pmu mappings: intel_bts = 6, uncore_cbox_5 = 21, uncore_ha_0 = 8, uncore_imc_2 = 9, uncore_cbox_3 = 19, cstate_pkg = 25, breakpoint = 5, uncore_imc_0 = 11, uncore_ubox = 15, uncore
# HEADER_CACHE info available, use -I to display
# missing features: HEADER_TRACING_DATA HEADER_BRANCH_STACK HEADER_GROUP_DESC HEADER_AUXTRACE HEADER_STAT 
# ========

let me know if you need more info.

Btw., note that there's also this warning:

  unwind: target platform=x86 is not supported

(but that's unrelated to this commit.)

Thanks,

	Ingo

Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Arnaldo Carvalho de Melo]

Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > +++ b/tools/perf/util/evsel.c
> > @@ -273,6 +273,11 @@ struct perf_evsel *perf_evsel__new_cycles(void)
> >  	event_attr_init(&attr);
> > +	/*
> > +	 * Unnamed union member, not supported as struct member named
> > +	 * initializer in older compilers such as gcc 4.4.7
> > +	 */
> > +	attr.sample_period = 1;
  
> >  	perf_event_attr__set_max_precise_ip(&attr);
 
> Hm, so this really broke perf for me on my main system - 'perf top' and 'perf 
> report' only shows:
 
>  triton:~/tip> perf report --stdio
>  unwind: target platform=x86 is not supported
>  unwind: target platform=x86 is not supported
>  unwind: target platform=x86 is not supported
>  # To display the perf.data header info, please use --header/--header-only options.
>  # Total Lost Samples: 0

>  # Samples: 921K of event 'cycles:ppp'
>  # Event count (approx.): 921045

>  # Overhead  Command    Shared Object     Symbol              
>  # ........  .........  ................  ....................
>     99.93%  hackbench  [kernel.vmlinux]  [k] native_write_msr
>      0.07%  perf       [kernel.vmlinux]  [k] native_write_msr
 
> the bisection result is unambiguous:
 
>    7fd1d092b4337831d7ccbf3a74c07cb0b2089023 is the first bad commit
 
> proper output would be:
 
>  ...
>  # Total Lost Samples: 0
>  #
>  # Samples: 9K of event 'cycles'
>  # Event count (approx.): 4378583062
>  #
>  # Overhead  Command    Shared Object     Symbol                                 
>  # ........  .........  ................  .......................................
>      4.32%  hackbench  [kernel.vmlinux]  [k] copy_user_enhanced_fast_string
>      4.02%  hackbench  [kernel.vmlinux]  [k] unix_stream_read_generic
>      3.75%  hackbench  [kernel.vmlinux]  [k] filemap_map_pages
>      3.06%  hackbench  [kernel.vmlinux]  [k] __check_object_size
>      2.44%  hackbench  [kernel.vmlinux]  [k] _raw_spin_lock_irqsave
>      2.32%  hackbench  [kernel.vmlinux]  [k] native_queued_spin_lock_slowpath
>      2.22%  hackbench  [kernel.vmlinux]  [k] entry_SYSENTER_compat
>      1.90%  hackbench  [vdso]            [.] __vdso_gettimeofday
>      1.80%  hackbench  [kernel.vmlinux]  [k] _raw_spin_lock
>      1.80%  hackbench  [kernel.vmlinux]  [k] skb_set_owner_w
>      1.67%  hackbench  [kernel.vmlinux]  [k] kmem_cache_free
>      1.52%  hackbench  [kernel.vmlinux]  [k] skb_release_data
>      1.48%  hackbench  [kernel.vmlinux]  [k] common_file_perm
>      1.45%  hackbench  [kernel.vmlinux]  [k] page_fault
>      1.45%  hackbench  [kernel.vmlinux]  [k] cmpxchg_double_slab.isra.62
>      1.42%  hackbench  [kernel.vmlinux]  [k] new_sync_read
>      1.36%  hackbench  [kernel.vmlinux]  [k] __check_heap_object
> 
> Here's the hardware details:

No need for that, its simpler, brown paper bag, I concentrated on it not
returning -EINVAL and didn't test it enough, ditto with the other guys
that tested this on s/390 :-\

The default case gets the precise_ip right, i.e. 3 in this broadwell machine,
but remained with the sample_period=1 used to probe it, ugh.

[root@jouet ~]# perf record usleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.021 MB perf.data (69 samples) ]
[root@jouet ~]# perf evlist -v
cycles:ppp: size: 112, { sample_period, sample_freq }: 1, sample_type: IP|TID|TIME, disabled: 1, inherit: 1, mmap: 1, comm: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1


If we use 'cycles:P' explicitely we can see that it uses the default sample_freq:

[root@jouet ~]# perf record -e cycles:P usleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.018 MB perf.data (8 samples) ]
[root@jouet ~]# perf evlist -v
cycles:P: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, enable_on_exec: 1, task: 1, precise_ip: 3, sample_id_all: 1, mmap2: 1, comm_exec: 1
[root@jouet ~]#

Can you try with the patch below, which is hackish but the minimal fix at this
point. Later I'll come up with a way of returning a fully configured cycles
evsel, which will make the tools code simpler, moving more stuff to the
libraries.

I'll look into the unwind case, where SRCARCH is being passed to the unwind
code uses both x86_64, not x86 (probably uses i386 or x86_32 for the 32-bit case).

- Arnaldo

diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index a7ce529ca36c..cda44b0e821c 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -276,10 +276,17 @@ struct perf_evsel *perf_evsel__new_cycles(void)
 	/*
 	 * Unnamed union member, not supported as struct member named
 	 * initializer in older compilers such as gcc 4.4.7
+	 *
+	 * Just for probing the precise_ip:
 	 */
 	attr.sample_period = 1;
 
 	perf_event_attr__set_max_precise_ip(&attr);
+	/*
+	 * Now let the usual logic to set up the perf_event_attr defaults
+	 * to kick in when we return and before perf_evsel__open() is called.
+	 */
+	attr.sample_period = 0;
 
 	evsel = perf_evsel__new(&attr);
 	if (evsel == NULL)

Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Ingo Molnar]

* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Can you try with the patch below, which is hackish but the minimal fix at this
> point. Later I'll come up with a way of returning a fully configured cycles
> evsel, which will make the tools code simpler, moving more stuff to the
> libraries.

Yeah, this patch on top of your tree seems to work better now.

Thanks,

	Ingo

Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Arnaldo Carvalho de Melo]

Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
> 
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> 
> > Can you try with the patch below, which is hackish but the minimal fix at this
> > point. Later I'll come up with a way of returning a fully configured cycles
> > evsel, which will make the tools code simpler, moving more stuff to the
> > libraries.
> 
> Yeah, this patch on top of your tree seems to work better now.

So how do we proceed, do you want to keep these two as separate or can I
squash them together, fix that problem with the unwind library and
provide a new perf/urgent for you to use?

Off to breakfast now tho :-)

- Arnaldo

Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Arnaldo Carvalho de Melo]

Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
>  triton:~/tip> perf report --stdio
>  unwind: target platform=x86 is not supported
>  unwind: target platform=x86 is not supported
>  unwind: target platform=x86 is not supported
>  unwind: target platform=x86 is not supported
>  unwind: target platform=x86 is not supported
>  unwind: target platform=x86 is not supported
>  unwind: target platform=x86 is not supported
>  unwind: target platform=x86 is not supported

> # ========
> # captured on: Wed Jun 14 07:34:42 2017
> # hostname : triton
> # os release : 4.10.0-23-generic
> # perf version : 4.12.rc5.g9688eb
> # arch : x86_64
> # nrcpus online : 12
> # nrcpus avail : 12
> # cpudesc : Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz
> # cpuid : GenuineIntel,6,62,4
> # total memory : 65917012 kB
> # cmdline : /home/mingo/bin/perf record /home/mingo/hackbench 10 

> let me know if you need more info.
> 
> Btw., note that there's also this warning:
> 
>   unwind: target platform=x86 is not supported
> 
> (but that's unrelated to this commit.)

Ok, what distro? Do you have libunwind-devel installed? I couldn't
reproduce this one here with/without it installed, to test I build it
with:

 make ARCH=x86_64 O=/tmp/build/perf -C tools/perf install-bin

and without that ARCH= setting, then I record with:

  perf record --call-graph dwarf -a sleep 2

and try what you said emitted that warning:

  perf report --stdio

- Arnaldo

perf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Arnaldo Carvalho de Melo]

Em Wed, Jun 14, 2017 at 10:29:47AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
> >  triton:~/tip> perf report --stdio
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> 
> > # ========
> > # captured on: Wed Jun 14 07:34:42 2017
> > # hostname : triton
> > # os release : 4.10.0-23-generic
> > # perf version : 4.12.rc5.g9688eb
> > # arch : x86_64
> > # nrcpus online : 12
> > # nrcpus avail : 12
> > # cpudesc : Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz
> > # cpuid : GenuineIntel,6,62,4
> > # total memory : 65917012 kB
> > # cmdline : /home/mingo/bin/perf record /home/mingo/hackbench 10 
> 
> > let me know if you need more info.
> > 
> > Btw., note that there's also this warning:
> > 
> >   unwind: target platform=x86 is not supported
> > 
> > (but that's unrelated to this commit.)
> 
> Ok, what distro? Do you have libunwind-devel installed? I couldn't
> reproduce this one here with/without it installed, to test I build it
> with:
> 
>  make ARCH=x86_64 O=/tmp/build/perf -C tools/perf install-bin
> 
> and without that ARCH= setting, then I record with:
> 
>   perf record --call-graph dwarf -a sleep 2
> 
> and try what you said emitted that warning:
> 
>   perf report --stdio

So, the "unwind: target platform=x86 is not supported" comes only from:

a  tools/perf/util/unwind-libunwind.c

That is linked by:

  $ grep libunwind-local tools/perf/util/Build 
  libperf-$(CONFIG_LOCAL_LIBUNWIND)    += unwind-libunwind-local.o
  $

And here CONFIG_LOCAL_LIBUNWIND is detected:

  [acme@jouet linux]$ grep CONFIG_LOCAL_LIBUNWIND /tmp/build/perf/.config-detected
  CONFIG_LOCAL_LIBUNWIND=y
  [acme@jouet linux]$ 

And that message is there:

  [acme@jouet linux]$ strings ~/bin/perf | grep "unwind: target platform="
  unwind: target platform=%s is not supported
  [acme@jouet linux]$

So the only way for get to that point would be for
local_unwind_libunwind_ops to be NULL, which it will be if its __weak
definition seting it to zero isn't overriden by...

tools/perf/util/unwind-libunwind-local.c

#ifndef REMOTE_UNWIND_LIBUNWIND 
struct unwind_libunwind_ops * 
local_unwind_libunwind_ops = &_unwind_libunwind_ops;
#endif 

And what defines it is...

tools/perf/util/libunwind/x86_32.c:#define REMOTE_UNWIND_LIBUNWIND

(and a arm64 file, but lets leave that aside, seems unrelated to this
case)

That will get built by...

tools/perf/util/Build:libperf-$(CONFIG_LIBUNWIND_X86)      += libunwind/x86_32.o

[acme@jouet linux]$ grep CONFIG_LIBUNWIND_X86 /tmp/build/perf/.config-detected
[acme@jouet linux]$

Ingo, are you doing something unusual as building a 32-bit perf to read a
62-bit perf.data file?

Jiri, can you help here? Do you need more info?

- Arnaldo

Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Ingo Molnar]

* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
> > 
> > * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > 
> > > Can you try with the patch below, which is hackish but the minimal fix at this
> > > point. Later I'll come up with a way of returning a fully configured cycles
> > > evsel, which will make the tools code simpler, moving more stuff to the
> > > libraries.
> > 
> > Yeah, this patch on top of your tree seems to work better now.
> 
> So how do we proceed, do you want to keep these two as separate or can I
> squash them together, fix that problem with the unwind library and
> provide a new perf/urgent for you to use?
> 
> Off to breakfast now tho :-)

Your call: I had to unpull, so feel free to rebase your urgent branch.

Thanks,

	Ingo

Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Ingo Molnar]

* Arnaldo Carvalho de Melo <acme@kernel.org> wrote:

> Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
> >  triton:~/tip> perf report --stdio
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> >  unwind: target platform=x86 is not supported
> 
> > # ========
> > # captured on: Wed Jun 14 07:34:42 2017
> > # hostname : triton
> > # os release : 4.10.0-23-generic
> > # perf version : 4.12.rc5.g9688eb
> > # arch : x86_64
> > # nrcpus online : 12
> > # nrcpus avail : 12
> > # cpudesc : Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz
> > # cpuid : GenuineIntel,6,62,4
> > # total memory : 65917012 kB
> > # cmdline : /home/mingo/bin/perf record /home/mingo/hackbench 10 
> 
> > let me know if you need more info.
> > 
> > Btw., note that there's also this warning:
> > 
> >   unwind: target platform=x86 is not supported
> > 
> > (but that's unrelated to this commit.)
> 
> Ok, what distro? Do you have libunwind-devel installed? [...]

Ubuntu, and the build says:

Auto-detecting system features:
...                         dwarf: [ on  ]
...            dwarf_getlocations: [ on  ]
...                         glibc: [ on  ]
...                          gtk2: [ on  ]
...                      libaudit: [ on  ]
...                        libbfd: [ on  ]
...                        libelf: [ on  ]
...                       libnuma: [ on  ]
...        numa_num_possible_cpus: [ on  ]
...                       libperl: [ on  ]
...                     libpython: [ on  ]
...                      libslang: [ on  ]
...                     libcrypto: [ on  ]
...                     libunwind: [ on  ]
...            libdw-dwarf-unwind: [ on  ]
...                          zlib: [ on  ]
...                          lzma: [ on  ]
...                     get_cpuid: [ on  ]
...                           bpf: [ on  ]

so it's a maximum-features build, right?

Here's the unwind libraries:

triton:~/tip> dpkg -l | grep unwind
ii  libunwind-dev                                        1.1-4.1ubuntu2                                       amd64        library to determine the call-chain of a program - development
ii  libunwind8                                           1.1-4.1ubuntu2                                       amd64        library to determine the call-chain of a program - runtime
ii  libunwind8-dev                                       1.1-4.1ubuntu2                                       amd64        library to determine the call-chain of a program - development

libunwind-dev is installed it appears.

Let me know if you want me to run other tests.

Thanks,

	Ingo

Re: perf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Jiri Olsa]

On Wed, Jun 14, 2017 at 10:52:42AM -0300, Arnaldo Carvalho de Melo wrote:

SNIP

> 
> And what defines it is...
> 
> tools/perf/util/libunwind/x86_32.c:#define REMOTE_UNWIND_LIBUNWIND
> 
> (and a arm64 file, but lets leave that aside, seems unrelated to this
> case)
> 
> That will get built by...
> 
> tools/perf/util/Build:libperf-$(CONFIG_LIBUNWIND_X86)      += libunwind/x86_32.o
> 
> [acme@jouet linux]$ grep CONFIG_LIBUNWIND_X86 /tmp/build/perf/.config-detected
> [acme@jouet linux]$
> 
> Ingo, are you doing something unusual as building a 32-bit perf to read a
> 62-bit perf.data file?
> 
> Jiri, can you help here? Do you need more info?

hum, looks like local unwind support wasn't compiled in for some reason

Ingo, what's the arch of host and perf data?

thanks,
jirka

Re: perf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Jiri Olsa]

On Wed, Jun 14, 2017 at 04:19:51PM +0200, Jiri Olsa wrote:
> On Wed, Jun 14, 2017 at 10:52:42AM -0300, Arnaldo Carvalho de Melo wrote:
> 
> SNIP
> 
> > 
> > And what defines it is...
> > 
> > tools/perf/util/libunwind/x86_32.c:#define REMOTE_UNWIND_LIBUNWIND
> > 
> > (and a arm64 file, but lets leave that aside, seems unrelated to this
> > case)
> > 
> > That will get built by...
> > 
> > tools/perf/util/Build:libperf-$(CONFIG_LIBUNWIND_X86)      += libunwind/x86_32.o
> > 
> > [acme@jouet linux]$ grep CONFIG_LIBUNWIND_X86 /tmp/build/perf/.config-detected
> > [acme@jouet linux]$
> > 
> > Ingo, are you doing something unusual as building a 32-bit perf to read a
> > 62-bit perf.data file?
> > 
> > Jiri, can you help here? Do you need more info?
> 
> hum, looks like local unwind support wasn't compiled in for some reason
> 
> Ingo, what's the arch of host and perf data?

also "make clean && make VF=1 V=1" output would help

thanks,
jirka

Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Arnaldo Carvalho de Melo]

Em Wed, Jun 14, 2017 at 03:55:22PM +0200, Ingo Molnar escreveu:
> 
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> 
> > Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
> > > 
> > > * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > > 
> > > > Can you try with the patch below, which is hackish but the minimal fix at this
> > > > point. Later I'll come up with a way of returning a fully configured cycles
> > > > evsel, which will make the tools code simpler, moving more stuff to the
> > > > libraries.
> > > 
> > > Yeah, this patch on top of your tree seems to work better now.
> > 
> > So how do we proceed, do you want to keep these two as separate or can I
> > squash them together, fix that problem with the unwind library and
> > provide a new perf/urgent for you to use?
> > 
> > Off to breakfast now tho :-)
> 
> Your call: I had to unpull, so feel free to rebase your urgent branch.

Ok, I'll rebase it, prepare another pull req after we nail down the
unwind one.

- Arnaldo

Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Arnaldo Carvalho de Melo]

Em Wed, Jun 14, 2017 at 04:06:01PM +0200, Ingo Molnar escreveu:
> 
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> 
> > Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
> > >  triton:~/tip> perf report --stdio
> > >  unwind: target platform=x86 is not supported
> > >  unwind: target platform=x86 is not supported
> > >  unwind: target platform=x86 is not supported
> > >  unwind: target platform=x86 is not supported
> > >  unwind: target platform=x86 is not supported
> > >  unwind: target platform=x86 is not supported
> > >  unwind: target platform=x86 is not supported
> > >  unwind: target platform=x86 is not supported
> > 
> > > # ========
> > > # captured on: Wed Jun 14 07:34:42 2017
> > > # hostname : triton
> > > # os release : 4.10.0-23-generic
> > > # perf version : 4.12.rc5.g9688eb
> > > # arch : x86_64
> > > # nrcpus online : 12
> > > # nrcpus avail : 12
> > > # cpudesc : Intel(R) Core(TM) i7-4960X CPU @ 3.60GHz
> > > # cpuid : GenuineIntel,6,62,4
> > > # total memory : 65917012 kB
> > > # cmdline : /home/mingo/bin/perf record /home/mingo/hackbench 10 
> > 
> > > let me know if you need more info.
> > > 
> > > Btw., note that there's also this warning:
> > > 
> > >   unwind: target platform=x86 is not supported
> > > 
> > > (but that's unrelated to this commit.)
> > 
> > Ok, what distro? Do you have libunwind-devel installed? [...]
> 
> Ubuntu, and the build says:
> 
> Auto-detecting system features:
> ...                         dwarf: [ on  ]
> ...            dwarf_getlocations: [ on  ]
> ...                         glibc: [ on  ]
> ...                          gtk2: [ on  ]
> ...                      libaudit: [ on  ]
> ...                        libbfd: [ on  ]
> ...                        libelf: [ on  ]
> ...                       libnuma: [ on  ]
> ...        numa_num_possible_cpus: [ on  ]
> ...                       libperl: [ on  ]
> ...                     libpython: [ on  ]
> ...                      libslang: [ on  ]
> ...                     libcrypto: [ on  ]
> ...                     libunwind: [ on  ]
> ...            libdw-dwarf-unwind: [ on  ]
> ...                          zlib: [ on  ]
> ...                          lzma: [ on  ]
> ...                     get_cpuid: [ on  ]
> ...                           bpf: [ on  ]
> 
> so it's a maximum-features build, right?
> 
> Here's the unwind libraries:
> 
> triton:~/tip> dpkg -l | grep unwind
> ii  libunwind-dev                                        1.1-4.1ubuntu2                                       amd64        library to determine the call-chain of a program - development
> ii  libunwind8                                           1.1-4.1ubuntu2                                       amd64        library to determine the call-chain of a program - runtime
> ii  libunwind8-dev                                       1.1-4.1ubuntu2                                       amd64        library to determine the call-chain of a program - development

Ok, but it is libunwind version 8, so this should narrow down the
problem, probably this one doesn't have that REMOTE_UNWIND_LIBUNWIND
somewhow, Jiri?

- Arnaldo

> 
> libunwind-dev is installed it appears.
> 
> Let me know if you want me to run other tests.
> 
> Thanks,
> 
> 	Ingo

Re: perf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Arnaldo Carvalho de Melo]

Em Wed, Jun 14, 2017 at 04:19:51PM +0200, Jiri Olsa escreveu:
> On Wed, Jun 14, 2017 at 10:52:42AM -0300, Arnaldo Carvalho de Melo wrote:
> 
> SNIP
> 
> > 
> > And what defines it is...
> > 
> > tools/perf/util/libunwind/x86_32.c:#define REMOTE_UNWIND_LIBUNWIND
> > 
> > (and a arm64 file, but lets leave that aside, seems unrelated to this
> > case)
> > 
> > That will get built by...
> > 
> > tools/perf/util/Build:libperf-$(CONFIG_LIBUNWIND_X86)      += libunwind/x86_32.o
> > 
> > [acme@jouet linux]$ grep CONFIG_LIBUNWIND_X86 /tmp/build/perf/.config-detected
> > [acme@jouet linux]$
> > 
> > Ingo, are you doing something unusual as building a 32-bit perf to read a
> > 62-bit perf.data file?
> > 
> > Jiri, can you help here? Do you need more info?
> 
> hum, looks like local unwind support wasn't compiled in for some reason
> 
> Ingo, what's the arch of host and perf data?

amd64/x86_64, ubuntu, libunwind version 8, perhaps this version has a
problem? See the other message I replied to Ingo, added you to the CC.

- Arnaldo

Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

[Arnaldo Carvalho de Melo]

Em Wed, Jun 14, 2017 at 04:06:01PM +0200, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
> > >  triton:~/tip> perf report --stdio
> > >  unwind: target platform=x86 is not supported

> so it's a maximum-features build, right?

looks  like
 
> Here's the unwind libraries:
> 
> triton:~/tip> dpkg -l | grep unwind
> ii  libunwind-dev   1.1-4.1ubuntu2  amd64  library to determine the call-chain of a program - development
> ii  libunwind8      1.1-4.1ubuntu2  amd64  library to determine the call-chain of a program - runtime
> ii  libunwind8-dev  1.1-4.1ubuntu2  amd64  library to determine the call-chain of a program - development
 
> libunwind-dev is installed it appears.
 
> Let me know if you want me to run other tests.

Couldn't reproduce so far :-\ I am trying it on a docker container with
Ubuntu 16.04, is that the version you're using, seems to be the 16.04,
at least the packages above listed are the same as in my container...

Also it would be nice to see if this is something introduced by Jiada's
patch:

Author: Jiada Wang <jiada_wang@mentor.com>
Date:   Sun Apr 9 20:02:37 2017 -0700

    perf tools: Fix build with ARCH=x86_64

---------------------------

I.e.  the other patch in my perf/urgent branch, does this warning go
away if you apply just the first patch in my perf/urgent branch as of
now?

Here is my testing:

root@5754d7c06d56:/# perf record -F 10000 --call-graph dwarf sleep 5
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.118 MB perf.data (14 samples) ]
root@5754d7c06d56:/# perf report --stdio --dsos '[kernel.kallsyms]' 2>&1 | head -20
# To display the perf.data header info, please use --header/--header-only options.
#
# dso: [kernel.kallsyms]
#
# Total Lost Samples: 0
#
# Samples: 14  of event 'cycles:ppp'
# Event count (approx.): 1085705
#
# Children      Self  Command  Symbol                        
# ........  ........  .......  ..............................
#
    28.16%     0.00%  sleep    [k] page_fault
            |
            ---page_fault
               do_page_fault
               __do_page_fault
               handle_mm_fault
               |          
               |--17.82%--__handle_mm_fault
root@5754d7c06d56:/# grep Ubuntu /etc/os-release 
NAME="Ubuntu"
PRETTY_NAME="Ubuntu 16.04.2 LTS"
root@5754d7c06d56:/#

- Arnaldo

- Arnaldo