On 06/07/23 09:39, Paul E. McKenney wrote: > On Thu, Jul 06, 2023 at 01:40:14PM +0200, Frederic Weisbecker wrote: >> On Thu, Jul 06, 2023 at 12:30:46PM +0100, Valentin Schneider wrote: >> > I'm trying to grok how this impacts RCU, IIUC most of RCU mostly cares about the >> > even/odd-ness of the thing, and rcu_gp_fqs() cares about the actual value >> > but only to check if it has changed over time (rcu_dynticks_in_eqs_since() >> > only does a !=). >> > >> > I'm rephrasing here to make sure I get it - is it then that the worst case >> > here is 2^(dynticks_counter_size) transitions happen between saving the >> > dynticks snapshot and checking it again, so RCU waits some more? >> >> That's my understanding as well but I have to defer on Paul to make sure I'm >> not overlooking something. > > That does look plausible to me. > > And yes, RCU really cares about whether its part of this counter has > been a multiple of two during a given interval of time, because this > indicates that the CPU has no pre-existing RCU readers still active. > One way that this can happen is for that value to be a multiple of two > at some point in time. The other way that this can happen is for the > value to have changed. No matter what the start and end values, if they > are different, the counter must necessarily have at least passed through > multiple of two in the meantime, again guaranteeing that any RCU readers > that around when the count was first fetched have now finished. > Thank you for the demystification! > But we should take the machine's opinions much more seriously than we > take any of our own opinions. Heh :-) > Why not adjust RCU_DYNTICKS_IDX so as > to crank RCU's portion of this counter down to (say) two or three bits > and let rcutorture have at it on TREE04 or TREE07, both of which have > nohz_full CPUs? > > Maybe also adjust mkinitrd.sh to make the user/kernel transitions more > frequent? > > Please note that I do -not- recommend production use of a three-bit > (let alone a two-bit) RCU portion because this has a high probability > of excessively extending grace periods. But it might be good to keep > a tiny counter as a debug option so that we regularly rcutorture it. > Sounds sensible, I'll add that to my v2 todolist. Thanks! > Thanx, Paul
