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). > > 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
