launch perf from hotspot

[milianw]

Allow running perf from within a nice launcher GUI in hotspot

This should allow multiple user-configurable analysis types, to select different event sources for perf, or do off-cpu VS. on-cpu profiling - or both at the same time.

As a first iteration, this only needs to run on localhost.

[tmcguire]

For a novice, troubleshooting information is important - if something went wrong when launching perf, how to fix that? I believe perf itself already gives nice output in many cases - it would be useful to simply show that output to the hotspot user. Example:

WARNING: Kernel address maps (/proc/{kallsyms,modules}) are restricted,
check /proc/sys/kernel/kptr_restrict.

Samples in kernel functions may not be resolved if a suitable vmlinux
file is not found in the buildid cache or in the vmlinux path.

Samples in kernel modules won't be resolved at all.

If some relocation was applied (e.g. kexec) symbols may be misresolved
even with a suitable vmlinux or kallsyms file.

Perf session creation failed.

[tmcguire]

In addition, warning the user when the perf version is to old and certain features won't be supported would be a nice touch.

[milianw]

we need to support three cases:

• lauch new process
  • use file selector (e.g. KUrlRequester) to select an existing binary (executable file)
  • free-form line edit to add command line arguments for the binary
  • table of custom environment variables
• attach to process(es)
  • use KSysGuard to show active processes
  • then take the PID of the selected process(es) and attach to them via --pid PID1,PID2 in the perf record call
• system wide
  • "simply" run perf record -a as root
    Note that systemwide will potentially require sudo rights, so we need to figure out how to do that correctly... Maybe use polkit (via the KDE libraries) for that? Needs to be researched.

for all the above, the user also needs to select the unwinding method, i.e. a drop down in this order:

• DWARF
• none
• fp
• lbr (only on intel hardware that actually has this feature, not sure how to detect that, needs to be researched)

additionally, the event type should be selectable. This should default to nothing, which internally uses the smart perf heuristics (i.e. cycles:ppp if available). Otherwise, if possible, show the categorized events form perf list in a smart way. Note that multiple events can be selected, and modifiers like :k or :u etc. can be applied. But for starters a free-form line edit could be used for that I guess (see below)

additionally a free-form line edit should cover all other cases that we did not think about yet. best memoize the contents here to restore that across launches/hotspot restarts

[milianw]

Also note what Thomas wrote above, we need to ensure that perf record actually works properly before launching. So we need to check permissions and adapt them (temporarily!) as needed (cf. https://github.com/milianw/shell-helpers/blob/master/perf-init) - again we need to figure out how to do that properly, polkit?

[milianw]

Also in addition to the perf list visualization, a couple of presets would be useful. like:

• default (whatever perf does as default)
• cycles,instructions
• cycles,instructions,cache-misses,branch-misses

the above could potentially use event groups (man perf record, but probably needs plumbing in perfparser too)

in the future this could then be used for off-cpu profiling purposes too (but other stuff needs to be implemented for that first)

[milianw]

what's missing so far is only the "system wide" mode, which is kinda blocked by #90, I'll keep this open for now