On Sat, Jan 10, 2026 at 8:14 AM Steven Rostedt <[email protected]> wrote: > > On Fri, 9 Jan 2026 16:35:10 -0800 > Alexei Starovoitov <[email protected]> wrote: > > > migrate_enable/disable() wasn't inlined for a long time. > > It bothered us enough, since sleepable bpf is the main user > > of it besides RT, so we made an effort to inline it. > > It did bother us too. it went through lots of iterations to become more > efficient over the years (it was really bad in the beginning while > still in the rt-patch), and hopefully that will continue. > > > > > RT, at the same time, doesn't inline rt_spin_lock() itself > > so inlining migrate_disable() or not is not 10x at all. > > Benchmark spin_lock on RT in-tree and in-module and I bet > > there won't be a big difference. > > I'll put that on my todo list. But still, having migrate_disable a > function for modules and 100% inlined for in-kernel code just because > it needs access to a field in the run queue that doesn't need to be in > the run queue seems like it should be fixed.
There was plenty of discussion with Peter regarding different ways to inline migrate_disable. What was landed was the best option at that point, but feel free to restart the discussion. > > As for tracepoints, BPF is the only one that needs migrate disable. > It's not needed for ftrace or perf (although perf uses preempt > disable). It should be moved into the BPF callback code as perf has its > preempt disable in its callback code. > > If BPF doesn't care about the extra overhead of migrate_disable() for > modules, then why should XFS suffer from that too? The diff has nothing to do with bpf needs and/or bpf internals. It's really about being a good citizen of PREEMP_RT. bpf side already does migrate_disable, rcu_read_lock, srcu_fast/task_trace when necessary. Most of the time we don't rely on any external preempt state or rcu/srcu. Removing guard(preempt_notrace)(); from tracepoint invocation would be just fine for bpf. Simple remove will trigger bug on cant_sleep(), but that's a trivial fix.
