On Tue, May 07, 2024 at 03:48:18PM +0200, Frederic Weisbecker wrote: > Le Tue, Apr 30, 2024 at 11:17:22AM +0200, Valentin Schneider a écrit : > > The context_tracking.state RCU_DYNTICKS subvariable has been renamed to > > RCU_WATCHING, the dynticks prefix can go. > > > > Furthermore, the "in_eqs_since" part confuses me, as IIUC this only checks > > for a change in watching/eqs state, not that RCU transitionned *into* a > > EQS after the snapshot was taken. > > > > e.g. if > > snap = 0b1000 (EQS) > > and the following rcu_watching_snap(CPU) is: > > 0b1100 (watching) > > then > > rcu_watching_in_eqs_since(rdp, snap) -> true > > > > but because RCU was already in EQS at the time of the > > snap - it hasn't entered EQS "since" the snap was taken. > > > > Update the name to reflect that we're only looking at watching/EQS > > transitions, not specifically transitions into EQS. > > Indeed in practice the function only checks a change. But semantically it really > checks a trip to eqs because this function is only ever called after a failing > call to rcu_dynticks_in_eqs(). > > So not sure about that one rename. Paul? As you say, Valentin is technically correct. Me, I am having a hard time getting too excited one way or the other. ;-) I suggest thinking in terms of rate-bounding the change. If you do change it, don't change it again for a few years. Either way, should comments be changed or added? Of course, the scientific way to evaluate this is to whose a couple dozen people the old code and a couple dozen other people the new code, and see if one group or the other has statistically significantly lower levels of confusion. I don't see how this is feasible, but it is the (painfully) correct way. On the other hand, it would have the beneficial side effect of getting more people exposed to Linux-kernel-RCU internals. Unfortunately, it might also have the additional side effect of making them (more) annoyed at RCU. ;-) Thanx, Paul
