On Wed, Jul 31, 2024 at 12:17:49AM +0200, Frederic Weisbecker wrote: > Le Tue, Jul 30, 2024 at 07:23:58AM -0700, Paul E. McKenney a écrit : > > On Thu, Jul 25, 2024 at 04:32:46PM +0200, Frederic Weisbecker wrote: > > > Le Wed, Jul 24, 2024 at 04:43:13PM +0200, Valentin Schneider a écrit : > > > > -/* Turn on heavyweight RCU tasks trace readers on idle/user entry. */ > > > > -static __always_inline void rcu_dynticks_task_trace_enter(void) > > > > +/* Turn on heavyweight RCU tasks trace readers on kernel exit. */ > > > > +static __always_inline void rcu_task_trace_exit(void) > > > > > > Before I proceed on this last one, a few questions for Paul and others: > > > > > > 1) Why is rcu_dynticks_task_exit() not called while entering in NMI? > > > Does that mean that NMIs aren't RCU-Task read side critical sections? > > > > Because Tasks RCU Rude handles that case currently. So good catch, > > because this might need adjustment when we get rid of Tasks RCU Rude. > > And both rcu_dynticks_task_enter() and rcu_dynticks_task_exit() look safe > > to invoke from NMI handlers. Memory ordering needs checking, of course. > > > > Except that on architectures defining CONFIG_ARCH_WANTS_NO_INSTR, Tasks > > RCU should instead check the ct_kernel_enter_state(RCU_DYNTICKS_IDX) > > state, right? And on those architectures, I believe that > > rcu_dynticks_task_enter() and rcu_dynticks_task_exit() can just be no-ops. > > Or am I missing something here? > > I think rcu_dynticks_task_enter() and rcu_dynticks_task_exit() are > still needed anyway because the target task can migrate. So unless the rq is locked, > it's hard to match a stable task_cpu() with the corresponding RCU_DYNTICKS_IDX. Can it really migrate while in entry/exit or deep idle code? Or am I missing a trick here? > > > 2) Looking further into CONFIG_TASKS_TRACE_RCU_READ_MB=y, it seems to > > > allow for uses of rcu_read_[un]lock_trace() while RCU is not watching > > > (EQS). Is it really a good idea to support that? Are we aware of any > > > such potential usecase? > > > > I hope that in the longer term, there will be no reason to support this. > > Right now, architectures not defining CONFIG_ARCH_WANTS_NO_INSTR must > > support this because tracers really can attach probes where RCU is > > not watching. > > > > And even now, in architectures defining CONFIG_ARCH_WANTS_NO_INSTR, I > > am not convinced that the early incoming and late outgoing CPU-hotplug > > paths are handled correctly. RCU is not watching them, but I am not so > > sure that they are all marked noinstr as needed. > > Ok I see... If need be, the outgoing-CPU transition to RCU-not-watching could be delayed into arch-specific code. We already allow this for the incoming transition. Thanx, Paul
