On Fri, Oct 4, 2024 at 7:53 AM Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > > On 2024-10-04 16:52, Steven Rostedt wrote: > > On Fri, 4 Oct 2024 10:19:36 -0400 > > Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx> wrote: > > > >> The eBPF people want to leverage this. When I last discussed this with > >> eBPF maintainers, they were open to adapt eBPF after this infrastructure > >> series is merged. Based on this eBPF attempt from 2022: > >> > >> https://lore.kernel.org/lkml/c323bce9-a04e-b1c3-580a-783fde259d60@xxxxxx/ > > > > Sorry, I wasn't part of that discussion. > > > >> > >> The sframe code is just getting in shape (2024), but is far from being ready. > >> > >> Everyone appears to be waiting for this infrastructure work to go in > >> before they can build on top. Once this infrastructure is available, > >> multiple groups can start working on introducing use of this into their > >> own code in parallel. > >> > >> Four years into this effort, and this is the first time we're told we need > >> to adapt in-tree tracers to handle the page faults before this can go in. > >> > >> Could you please stop moving the goal posts ? > > > > I don't think I'm moving the goal posts. I was mentioning to show an > > in-tree user. If BPF wants this, I'm all for it. The only thing I saw was a > > generalization in the cover letter about perf, bpf and ftrace using > > faultible tracepoints. I just wanted to see a path for that happening. > > AFAIU eBPF folks are very eager to start making use of this, so we won't > have to wait long. I already gave my ack on BPF parts of this patch set, but I'll elaborate a bit more here for the record. There seems to be two things that's been discussed. First, preempt_disable() vs migrate_disable(). We only need the latter, but the former just preserves current behavior and I think it's fine, we can follow up with BPF-specific bits later to optimize and clean this up further. No big deal. Second, whether BPF can utilize sleepable (faultable) tracepoints right now with these changes. No, we need a bit more work (again, in BPF specific parts) to allow faultable tracepoint attachment for BPF programs. But it's a bit nuanced piece of code to get everything right, and it's best done by someone more familiar with BPF internals. So I wouldn't expect Mathieu to do this either. So, tl;dr, I think patches are fine as-is (from BPF perspective), and we'd like to see them applied and get to bpf-next for further development on top of that. > > Thanks, > > Mathieu > > -- > Mathieu Desnoyers > EfficiOS Inc. > https://www.efficios.com >
