On Sun, Apr 30, 2023 at 4:50 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > > On Sun, Apr 30, 2023 at 03:56:11PM -0400, Joel Fernandes wrote: > > Hello, > > Quick question (for educational purpose) for anyone - why does > > PREEMPT=n kernel not want to get help from __rcu_read_unlock() for > > expedited grace periods? > > > > Basically, with PREEMPT=y kernels, rcu_read_unlock_special.b.exp_hint > > is set to true, but for PREEMPT=n, no such thing is done. Furthermore, > > the __rcu_read_unlock() for PREEMPT=n does not help expedited GPs come > > to an end either. > > > > I am guessing the answer is, "no one cares about that", or "no one > > reported needing this", but if there is another reason why a PREEMPT=n > > kernel should not need it, do let me know :) > > Because PREEMPT=n kernels value fast rcu_read_unlock() more than they > value fast expedited grace periods. Ok, makes sense. > > To make it more interesting, it appears that CONFIG_PREEMPT=y where > > preemption is dynamically disabled, it _should_ have the effect of > > helping expedited GPs as far as I can see. Which further seems a > > difference between booting PREEMPT=n versus PREEMPT=y + booting with > > preemption turned off via boot option. > > Yes, very much so! > > So if you care deeply about fast expedited grace periods and less > so about smallish rcu_read_unlock() slowdowns, but otherwise want > non-preemptibility, CONFIG_PREEMPT_DYNAMIC=y and dynamically selecting > non-preemptible operation might be your best choice. Makes sense, thanks! - Joel
