Hi Alexei and Ben, This sounds awesome! Somewhat off-topic, I wonder if we could include the pyperf and ghc support in regular perf? I think there is an assumption that these languages are a minority concern, but I think everyone would benefit from being packaged with perf, being kept in sync with how the APIs evolve, code reuse, etc. Thanks, Ian On Fri, Jan 21, 2022 at 4:05 PM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Fri, Dec 17, 2021 at 1:53 PM Ben Gamari <ben@xxxxxxxxxxxxxxxx> wrote: > > > > Hi all, > > > > I have recently been exploring the possibility of using a > > BPF_PROG_TYPE_PERF_EVENT program to implement stack sampling for > > languages which do not use the platform's %sp for their stack pointer > > (in my case, GHC/Haskell [1], which on x86-64 uses %rbp for its stack > > pointer). Specifically, the idea is to use a sampling perf_events > > session with an eBPF overflow handler which locates the > > currently-running thread's stack and records it in the sample ringbuffer > > (see [2] for my current attempt). At this point I only care about > > user-space samples. > > > > However, I quickly ran up against the fact that perf_event's stack > > sampling logic (namely perf_output_sample_ustack) is called from an IRQ > > context. This appears to preclude use of a sleepable BPF program, which > > would be necessary to use bpf_copy_from_user. Indeed, the fact that the > > usual stack sampling logic uses copy_from_user_inatomic rather than > > copy_from_user suggests that this isn't a safe context for sleeping. > > > > So, I'm at this point a bit unclear on how to proceed. I can see a few > > possible directions forward, although none are particularly enticing: > > > > * Add a bpf_copy_from_user_atomic helper, which can be called from a > > non-sleepable context like a perf_events overflow handler. This would > > take the same set_fs() and pagefault_disable() precautions as > > perf_output_sample_ustack to ensure that the access is safe and aborts > > on fault. > > > > * Introduce a new BPF program type, > > BPF_PROG_TYPE_PERF_EVENT_STACK_LOCATOR, which can be invoked by > > perf_output_sample_ustack to locate the stack to be sampled. > > > > Do either of these ideas sound upstreamable? Perhaps there are other > > ideas on how to attack this general problem? I do not believe Haskell is > > alone in its struggle with the current inflexibility of stack sampling; > > the JVM introduced framepointer support specifically to allow callgraph > > sampling; however, dedicating a register and code to this seems like an > > unfortunate compromise, especially on x86-64 where registers are already > > fairly precious. > > > > Any thoughts or suggestions would be greatly appreciated. > > Hi Ben, > > if you're sampling the stack trace of the current process > there is no need for copy_from_user and sleepable. > The memory with the stack trace unlikely was paged out. > So normal bpf_probe_read_user() will work fine. > > This approach was used to implement 'pyperf'. > It walks python stack traces: > https://github.com/iovisor/bcc/tree/master/examples/cpp/pyperf > What you're trying to do for haskel sounds very similar.
