On Thu, 6 Nov 2025 17:04:33 -0800
"Paul E. McKenney" <[email protected]> wrote:
> >
> > It gets a bit more confusing. We see "migrate disabled" (the last number)
> > except when preemption is enabled.
>
> Huh. Would something like "...11" indicate that both preemption and
> migration are disabled?
Preemption was disabled when coming in.
>
> > That's because in your code, we only do
> > the migrate dance when preemption is disabled:
> >
> > > + if (IS_ENABLED(CONFIG_PREEMPT_RT) && preemptible()) {
> > > \
>
> You lost me on this one. Wouldn't the "preemptible()" condition in that
> "if" statement mean that migration is disabled only when preemption
> is *enabled*?
>
> What am I missing here?
So preemption is disabled when the event was hit. That would make
"preemptible()" false, and we will then up the preempt_count again and
not disable migration.
The code that records the preempt count expects the tracing code to
increment the preempt_count, so it decrements it by one. Thus it records;
...1.
As migrate disable wasn't set.
>
> > > + guard(srcu_fast_notrace)(&tracepoint_srcu);
> > > \
> > > + guard(migrate)();
> > > \
> > > + __DO_TRACE_CALL(name, TP_ARGS(args));
> > > \
> > > + } else {
> > > \
> > > + guard(preempt_notrace)();
> > > \
> > > + __DO_TRACE_CALL(name, TP_ARGS(args));
> > > \
> > > + }
> >
> > And that will make accounting in the trace event callback much more
> > difficult, when it's sometimes disabling migration and sometimes disabling
> > preemption. It must do one or the other. It can't be conditional like that.
> >
> > With my update below, it goes back to normal:
> >
> > bash-1040 [004] d..2. 49.339890: lock_release:
> > 000000001d24683a tasklist_lock
> > bash-1040 [004] d..2. 49.339890: irq_enable:
> > caller=_raw_write_unlock_irq+0x28/0x50 parent=0x0
> > bash-1040 [004] ...1. 49.339891: lock_release:
> > 00000000246b21a5 rcu_read_lock
> > bash-1040 [004] ..... 49.339891: lock_acquire:
> > 0000000084e3738a read &mm->mmap_lock
> > bash-1040 [004] ..... 49.339892: lock_release:
> > 0000000084e3738a &mm->mmap_lock
> > bash-1040 [004] ..... 49.339892: lock_acquire:
> > 00000000f5b22878 read rcu_read_lock_trace
> > bash-1040 [004] ..... 49.339892: lock_acquire:
> > 0000000084e3738a read &mm->mmap_lock
> > bash-1040 [004] ..... 49.339893: lock_release:
> > 0000000084e3738a &mm->mmap_lock
> > bash-1040 [004] ..... 49.339893: sys_exit: NR 109 = 0
> > bash-1040 [004] ..... 49.339893: lock_acquire:
> > 0000000084e3738a read &mm->mmap_lock
> > bash-1040 [004] ..... 49.339894: lock_release:
> > 0000000084e3738a &mm->mmap_lock
> > bash-1040 [004] ..... 49.339894: sys_setpgid -> 0x0
> > bash-1040 [004] ..... 49.339895: lock_release:
> > 00000000f5b22878 rcu_read_lock_trace
> > bash-1040 [004] d.... 49.339895: irq_disable:
> > caller=do_syscall_64+0x37a/0x9a0 parent=0x0
> > bash-1040 [004] d.... 49.339895: irq_enable:
> > caller=do_syscall_64+0x167/0x9a0 parent=0x0
> > bash-1040 [004] d.... 49.339897: irq_disable:
> > caller=irqentry_enter+0x57/0x60 parent=0x0
> >
> > I did some minor testing of this patch both with and without PREEMPT_RT
> > enabled. This replaces this current patch. Feel free to use it.
>
> OK, I will add it with your SoB and give it a spin. Thank you!
Signed-off-by: Steve Rostedt (Google) <[email protected]>
Cheers,
-- Steve
