Re: [lmi] linux-perf in chroot via .deb abuse

[Vadim Zeitlin]

On Fri, 2 Oct 2020 23:06:27 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> Vadim--Do you think this approach is worse than trying to compile
GC> 'perf' in a chroot with the host's kernel version? It just seemed
GC> easier to try this way first.

 If it works, why not. I'm just afraid of running into weird problems and
losing a lot of time due to them -- something which normally shouldn't
happen if you just build the (same) kernel package inside chroot.

GC> Messages like:
GC>   Failed to read max cpus, using default of 4096
GC>   Cannot load tips.txt file, please install perf!
GC> imply that some part of perf is still missing.

 Yes, and while both of these messages are harmless enough, I'm worried
about the problems that don't result in any messages. But maybe I just
worry too much (should I worry about that?).

GC> This x86_64-pc-linux-gnu hotspot:
GC>    8.60%  lmi_cli_shared  libm-2.31.so         [.] expm1f64x
GC> looks up the symbol 'expm1f64x', so we needn't run 'addr2line'
GC> to decode its address, as was necessary with a different approach
GC> recently tried.

 As long as it works and gives you reasonable results, I don't see any
reason not to use it. After all, we're not interested in running perf per
se, but rather in getting something useful from it -- and you seem to have
this. If you ever run into some weird problems, it might not be worth your
time trying to debug them, however, but as long as you don't, everything is
good.

 Regards,
VZ

pgpB_cCXdgCUu.pgp
Description: PGP signature