On Tue, Nov 21, 2023 at 10:15:56PM +0000, Qais Yousef wrote: > On 11/22/23 15:26, Paul E. McKenney wrote: > > > > Either way; I'll follow what the crowd wants too :-) > > > > Usually a wise choice. ;-) > > > > But I must defer to the people using it. > > >From Android PoV I'd like to be able to boot with default disabled and allow > people to opt-in. At least for the time being until we have confidence no one > is caught with surprise if this caused unexpected problems. > > In the future it might default to on once it gets wider usage and testing. > > So having a new Kconfig to DEFAULT_OFF sounds good to me to enable a compile > time switch to pick the default with a boot time to further control. > > Which would be my plan for v2 unless I hear another suggestion in the coming > week (where I hope people would have had a chance to look and think about it). Sounds good to me! Silence will be interpreted as assent. ;-) Thanx, Paul > > > No need for the rcu_barrier() then? Only reason why we use the _cb flavour > > > > The module_param() parameters are processed during early boot, before > > the boot CPU has enabled interrupts. In fact, before rcu_init() > > is invoked, which is in turn long before the scheduler has started. > > Calling rcu_barrier() that early is not so good for your kernel's > > actuarial statistics. > > Ah, I missed that it is done that early. > > > > > I am guessing that the module_param_cb() processing happens somewhat > > later in the kernel's lifetime. > > > Thanks! > > -- > Qais Yousef
