Christian von Elm

We have to reopen this issue as my PR fails to address the root problem. this command line is fine in GNU tr but fails with uutils ``` tr '[:upper:][:lower:]'...

Yeah, this Issue is what that PR was all about

[According to this Stackoverflow answer](https://stackoverflow.com/questions/12213445/identifying-kernel-threads), one can check the `flags` field of `/proc/[pid]/stat` for the PF_KTHREAD bit to check if it is a kernel thread.

I have implemented this in the https://github.com/tud-zih-energy/lo2s/tree/issue-328-group-kernel-threads branch. please check if this matches your expectation. For me it looks fine in Vampir.

- Our target systems (mainly Barnard) support CO-RE as they come with Rocky Linux 8.6 - BPF can only be used with sudo. There does not exist some kind of...

Documenting how py-spy does it (roughly): 1. Read the location of the python binary from `/proc` 2. Parse Debug Symbols of the binary for the location of the `_PyRuntime` symbol....

Apparently, this is caused by the kernel. Everytime perf_event_open is called (which is a lot for --list-events as we check if we can `perf_event_open` every PMU event) the kernel has...

I can not recreate this on Intel Xeon Max 9468 or Core i9-12900K anymore, so I presume that the underlying problem for the perf_event_open slowness has been fixed in subsequent...

This seems to be generally caused by us missing PTRACE_EVENT_SOMETHING for the different kinds of creating offspring, for load reasons (my computer reached 500 something load during testing) `[14641106768213][pid: 64987][tid:...

I'm currently cleaning up the event reading code and I stumbled over this config check: ```cpp if (arguments.provided("metric-count") && !arguments.provided("metric-leader")) { Log::fatal()