Re: [GIT PULL] perf fixes

[Ingo Molnar <mingo@kernel.org>]

* Ingo Molnar <mingo@kernel.org> wrote:

> This actually works fine in practice. I just tried out a brand new kernel 
> with really old perf tooling in the v3.19 kernel, from 4.5 years ago:
> 
>   $ git checkout v3.19
>   $ cd tools/perf/
>   $ make install WERROR=0
> 
>   $ perf version
>   perf version 3.19.gbfa76d49
> 
>   $ perf top
> 
> This ancient version of 'perf top', 'perf record', 'perf report' works 
> just fine on the new kernel, despite passing in a smaller 'attr':
> 
>   [  558.408907] perf kABI size: 112
>   [  558.412855] perf uABI size: 104
> 
> when running new tooling on a new kernel the two sizes match:
> 
> [  331.598089] perf kABI size: 112
> [  331.602050] perf uABI size: 112
> 
> and everything works as usual.

Out of morbid curiosity I also tried out the v3.2 version of perf 
tooling, which is now more than 7.5 years old, and 'perf record' + 'perf 
report' is working fine on the latest kernel too:


  $ perf version
  perf version 3.2.dirty

  $ perf record ~/hackbench 20
  Time: 0.082
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.828 MB perf.data (~36166 samples) ]

  $ perf report --stdio
  ...
  # Overhead    Command      Shared Object                                      Symbol
  # ........  .........  .................  ..........................................
  #
     6.99%  hackbench  [kernel.kallsyms]  [k] queued_spin_lock_slowpath
     6.22%  hackbench  [kernel.kallsyms]  [k] entry_SYSENTER_compat
     4.06%  hackbench  [kernel.kallsyms]  [k] sysret32_from_system_call
     3.56%  hackbench  [kernel.kallsyms]  [k] do_fast_syscall_32
     3.40%  hackbench  [kernel.kallsyms]  [k] unix_stream_read_generic
     3.32%  hackbench  [kernel.kallsyms]  [k] _raw_spin_lock
     3.13%  hackbench  [kernel.kallsyms]  [k] __slab_free


It works despite 'perf record' using an ancient, 72 bytes long 'struct perf_attr' 
ABI:

  [ 3013.531125] perf kABI size: 112
  [ 3013.535097] perf uABI size: 72

If I'm reading the logs right then the perf ABI went through around ~15 
iterations in the v3.2..v5.4 timeframe that extended struct 
perf_event_attr - but binary compatibility was maintained with ancient 
tooling.

This is also useful for tooling bisectability: tooling should work on new 
and old kernels as well, even if a bisection point moves across ABI 
extension boundaries.

Thanks,

	Ingo