On Fri, Jan 03, 2025 at 11:50:29AM -0500, Joel Fernandes wrote: > On Thu, Jan 2, 2025 at 7:58 PM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > [...] > > > > Last question, do I need the -rt kernel for preempt RCU? > > > > > > No, CONFIG_PREEMPT=y suffices. > > > > > > Note that CONFIG_PREEMPT_RT=y, AKA -rt, also makes spinlocks (but not > > > raw spinlocks) be limited sleeplocks, and thus allows RCU read-side > > > critical sections to block when acquiring these sleeping "spinlocks". > > > But this is OK, because all of this is still subject to priority boosting. > > > > Should PREEMPT_RT kernels not throw warnings though when calling > > rcu_note_context_switch() in RCU read-side sections? > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/rcu/tree_plugin.h#n331 > > > > I don't run a PREEMPT_RT kernel myself so I can't confirm if these > > warnings somehow don't appear, but I figured it would be good to > > double check in this discussion. > > Please ignore my noise, Steven clarified for me in a meeting today > that preempt != 0 in that warning, when an a > "spinlock-coverted-to-rtmutex for PREEMPT_RT" blocks. So even though > the rtmutex blocks in an RCU read-side critical section. > > In other words, I believe rtmutex is the exception -- It can block in > an RCU read-side critical section on any kernel (PREEMPT_RT or > otherwise). I could stand corrected though but that's my current > understanding. RCU doesn't know about this distinction, it is just told preempt or not. The scheduler passes in @true when the sched_mode is greater than SM_NONE, which includes SM_RTLOCK_WAIT. But this latter is used only in -rt kernels, so that you cannot use rtmutexes in RCU read-side critical sections in non-rt kernels. So, in practice, portable code only gets to use spinlocks in RCU read-side critical sections. At least as of v6.12. ;-) Thanx, Paul
