On Wed, Mar 02, 2022 at 12:09:42PM +0100, Sebastian Andrzej Siewior wrote: > On 2022-03-01 21:42:17 [-0800], Paul E. McKenney wrote: > > There have been several different things requiring various pieces of RCU > > to be running quite early, and I need to do a bit of code archaeology to > > check this out. One of these is what forced me to move to expedited grace > > periods once the scheduler started. And the expedited grace periods do > > require the timers be working, at least in their current form. > > expedited as in synchronize_rcu_expedited()? Because we don't do this > but then only after boot so it probably doesn't change a thing and makes > other complicated. Expedited as in both synchronize_rcu_expedited() on the one hand and also synchronize_rcu() between the time that the scheduler is active and RCU has spawned its kthreads (AKA the "mid-boot dead zone"). I agree that the former is not important for you, especially if you boot with rcupdate.rcu_normal=1. But the mid-boot dead zone uses expedited grace periods because at that point in the process, the normal grace period cannot function. > > I vaguely recall tracing requiring call_rcu() extremely early (as > > in before rcu_init() is called), but that was not a problem because > > there was no requirement that the callback be invoked before the first > > couple of sets of initcalls had completed. The only challenge in this > > case was to avoid stomping on the callback lists at rcu_init() time, > > no timers required. > > Okay. > > > One straightforward approach would be to choose the call site of the > > rcu_tasks_initiate_self_tests() function based on whether or not the > > kernel was built with CONFIG_PREEMPT_RT. > > But then we have this change between RT and !RT due to other > limitations. But my understanding is correct that RT does not have a > working synchronize_rcu() in an early_initcall() while !RT does, right?
