On Tue, Feb 28, 2023 at 12:40:38AM +0100, Frederic Weisbecker wrote: > On Mon, Feb 27, 2023 at 03:05:02PM -0800, Paul E. McKenney wrote: > > On Mon, Feb 27, 2023 at 02:10:30PM -0500, Joel Fernandes wrote: > > > > The combination of sysfs manipulated by userspace and a kernel failsafe > > makes sense to me. Especially if by default triggering the failsafe > > splats. That way, bugs where userspace fails to update the sysfs file > > get caught. > > > > The non-default silent-failsafe mode is also useful to allow some power > > savings in advance of userspace getting the sysfs updating in place. > > And of course the default splatting setup can be used in internal testing > > with the release software being more tolerant of userspace foibles. > > I'm wondering, this is all about CONFIG_RCU_LAZY, right? Or does also expedited > GP turned off a bit early or late on boot matter for anybody in practice? Yes, if you provide 'rcu_normal_after_boot', then after the boot ends, it switches expedited GPs to normal ones. It is the same issue for expedited, the kernel's version of what is 'boot' is much shorter than what is actually boot. This is also the case with suspend/resume's rcu_pm_notify(). See the comment: /* * On non-huge systems, use expedited RCU grace periods to make suspend * and hibernation run faster. */ There also we turn on/off both lazy and expedited. I don't see why we shouldn't do it for boot. > So shouldn't we disable lazy callbacks by default when CONFIG_RCU_LAZY=y and then > turn it on with "sysctl kernel.rcu.lazy=1" only whenever userspace feels ready > about it? We can still keep the current call to rcu_end_inkernel_boot(). Hmm IMHO that would add more knobs for not much reason honestly. We already have CONFIG_RCU_LAZY default disabled, I really don't want to add more dependency (like user enables the config and does not see laziness). Thanks! - Joel
