On Sun, Apr 30, 2023 at 05:12:44PM -0400, Joel Fernandes wrote: > 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! Of course, if this is to be advertised at all widely, it would be good to actually measure it. But what else is new? ;-) Thanx, Paul
