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

2017-06-14 Thread Arnaldo Carvalho de Melo 
Em Wed, Jun 14, 2017 at 04:06:01PM +0200, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo  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 
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 1 --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

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

2017-06-14 Thread Arnaldo Carvalho de Melo 
Em Wed, Jun 14, 2017 at 04:06:01PM +0200, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo  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 
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 1 --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

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

2017-06-14 Thread 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: perf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

2017-06-14 Thread 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

2017-06-14 Thread Arnaldo Carvalho de Melo 
Em Wed, Jun 14, 2017 at 04:06:01PM +0200, Ingo Molnar escreveu:
> 
> * Arnaldo Carvalho de Melo  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-dev1.1-4.1ubuntu2   
> amd64library to determine the 
> call-chain of a program - development
> ii  libunwind8   1.1-4.1ubuntu2   
> amd64library to determine the 
> call-chain of a program - runtime
> ii  libunwind8-dev   1.1-4.1ubuntu2   
> amd64library 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: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

2017-06-14 Thread Arnaldo Carvalho de Melo 
Em Wed, Jun 14, 2017 at 04:06:01PM +0200, Ingo Molnar escreveu:
> 
> * Arnaldo Carvalho de Melo  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-dev1.1-4.1ubuntu2   
> amd64library to determine the 
> call-chain of a program - development
> ii  libunwind8   1.1-4.1ubuntu2   
> amd64library to determine the 
> call-chain of a program - runtime
> ii  libunwind8-dev   1.1-4.1ubuntu2   
> amd64library 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: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

2017-06-14 Thread Arnaldo Carvalho de Melo 
Em Wed, Jun 14, 2017 at 03:55:22PM +0200, Ingo Molnar escreveu:
> 
> * Arnaldo Carvalho de Melo  wrote:
> 
> > Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
> > > 
> > > * Arnaldo Carvalho de Melo  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

2017-06-14 Thread Arnaldo Carvalho de Melo 
Em Wed, Jun 14, 2017 at 03:55:22PM +0200, Ingo Molnar escreveu:
> 
> * Arnaldo Carvalho de Melo  wrote:
> 
> > Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
> > > 
> > > * Arnaldo Carvalho de Melo  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: perf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

2017-06-14 Thread 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: perf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

2017-06-14 Thread 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: perf: unwind: target platform=x86 not supported was: Re: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

2017-06-14 Thread 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

2017-06-14 Thread 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: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

2017-06-14 Thread Ingo Molnar 

* Arnaldo Carvalho de Melo  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-dev1.1-4.1ubuntu2 
  amd64library to determine the call-chain 
of a program - development
ii  libunwind8   1.1-4.1ubuntu2 
  amd64library to determine the call-chain 
of a program - runtime
ii  libunwind8-dev   1.1-4.1ubuntu2 
  amd64library 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: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

2017-06-14 Thread Ingo Molnar 

* Arnaldo Carvalho de Melo  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-dev1.1-4.1ubuntu2 
  amd64library to determine the call-chain 
of a program - development
ii  libunwind8   1.1-4.1ubuntu2 
  amd64library to determine the call-chain 
of a program - runtime
ii  libunwind8-dev   1.1-4.1ubuntu2 
  amd64library 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: [PATCH 1/2] perf evsel: Fix probing of precise_ip level for default cycles event

2017-06-14 Thread Ingo Molnar 

* Arnaldo Carvalho de Melo  wrote:

> Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
> > 
> > * Arnaldo Carvalho de Melo  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

2017-06-14 Thread Ingo Molnar 

* Arnaldo Carvalho de Melo  wrote:

> Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
> > 
> > * Arnaldo Carvalho de Melo  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

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

2017-06-14 Thread 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

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

2017-06-14 Thread 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

2017-06-14 Thread 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

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

2017-06-14 Thread 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

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

2017-06-14 Thread Arnaldo Carvalho de Melo 
Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
> 
> * Arnaldo Carvalho de Melo  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

2017-06-14 Thread Arnaldo Carvalho de Melo 
Em Wed, Jun 14, 2017 at 12:51:55PM +0200, Ingo Molnar escreveu:
> 
> * Arnaldo Carvalho de Melo  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

2017-06-14 Thread Ingo Molnar 

* Arnaldo Carvalho de Melo  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

2017-06-14 Thread Ingo Molnar 

* Arnaldo Carvalho de Melo  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

2017-06-14 Thread Arnaldo Carvalho de Melo 
Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo  wrote:
> > +++ b/tools/perf/util/evsel.c
> > @@ -273,6 +273,11 @@ struct perf_evsel *perf_evsel__new_cycles(void)
> > event_attr_init();
> > +   /*
> > +* 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();
 
> 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  CommandShared 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  CommandShared 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;

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

2017-06-14 Thread Arnaldo Carvalho de Melo 
Em Wed, Jun 14, 2017 at 07:45:01AM +0200, Ingo Molnar escreveu:
> * Arnaldo Carvalho de Melo  wrote:
> > +++ b/tools/perf/util/evsel.c
> > @@ -273,6 +273,11 @@ struct perf_evsel *perf_evsel__new_cycles(void)
> > event_attr_init();
> > +   /*
> > +* 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();
 
> 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  CommandShared 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  CommandShared 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;

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

2017-06-13 Thread Ingo Molnar 

* Arnaldo Carvalho de Melo  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();
> + /*
> +  * 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();

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  CommandShared 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  CommandShared 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

2017-06-13 Thread Ingo Molnar 

* Arnaldo Carvalho de Melo  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();
> + /*
> +  * 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();

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  CommandShared 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  CommandShared 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

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

2017-06-13 Thread Arnaldo Carvalho de Melo 
From: Arnaldo Carvalho de Melo 

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
  
0  int x86_pmu_hw_config(struct perf_event *event)
1  {
2 if (event->attr.precise_ip) {

   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;
  }

  # 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:(9c0065e1))
   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:(9c0065e1))
   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

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

2017-06-13 Thread Arnaldo Carvalho de Melo 
From: Arnaldo Carvalho de Melo 

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
  
0  int x86_pmu_hw_config(struct perf_event *event)
1  {
2 if (event->attr.precise_ip) {

   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;
  }

  # 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:(9c0065e1))
   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:(9c0065e1))
   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,