On Thu, Jul 30, 2026 at 06:31:12PM +0530, Shrikanth Hegde wrote:
> Hi Paul. Thanks for taking time looking into this.
>
> > > In current upstream, lazy is a preemption mode with preempt_enable being
> > > a preemptible point,
> > >
> > > 1. If PREEMPT_LAZY=y and PREEMPT_DYNAMIC=n, then PREEMPT_RCU=n. That
> > > seems wrong. It is supposed to
> > > do the preemption checks, since preempt_count is actual count with
> > > lazy preemption.
> >
> > Sorry, but no, not wrong at all. This is the way that it is supposed
> > to be. In this configuration, RCU readers explicitly disable preemption.
> > This gets us minimal RCU overhead on architectures such as x86 and arm64
> > that have prohibited CONFIG_PREEMPT_NONE and CONFIG_PREEMPT_VOLUNTARY.
>
> This is after 7.0 only right? Before that one could choose even on x86 and
> arm64 IIUC.
> After 7.0, even on powerpc, one cannot choose them anymore.
Yes, until quite recently, you could select CONFIG_PREEMPT_NONE and
CONFIG_PREEMPT_VOLUNTARY. Now you can do so only for architectures that
don't support preemption, if I recall correctly.
> > Not zero overhead, but minimal overhead given the constraints imposed by
> > CONFIG_PREEMPT_LAZY. This also prevents preemption of RCU readers, which
> > is extremely important on datacenter servers that have good and sufficient
> > quantities of memory, but which are not well-endowed with memory.
> >
> > > 2. PREEMPT_LAZY=y and PREEMPT_DYNAMIC=n and PREEMPT_LAZY=y and
> > > PREEMPT_DYNAMIC=y are supposed
> > > to be similar w.r.t to performance.
> >
> > RCU never made that promise. ;-)
> >
> > With PREMPT_DYNAMIC=y, RCU has no choice but to be preemptible, at
> > least unless and until someone decides to make RCU's preemptibility be
> > changeable at runtime (which I do not recommend). And we really do need
> > non-preemptible RCU for server workloads.
>
> most of the distros i see set PREMPT_DYNAMIC=y.
> I checked in SLES, RHEL. (I could be wrong here)
I believe that to be the case. But there are those of us who build our
own kernels and deploy them through large numbers of large datacenters.
> > So it is not just that RCU never made that promise, it is that RCU cannot
> > reasonably make that promise.
> >
> > > Promise of PREEMPT_DYNAMIC was
> > > the ability to
> > > switch at runtime based on the user workload and his/her preference.
> > > But with PREEMPT_LAZY=y and PREEMPT_DYNAMIC=y, there is additional
> > > cost due to PREEMPT_RCU.
> > > lazy being the middle ground w.r.t for decent performance, either
> > > PREEMPT_RCU should either kick in
> > > for both cases or bail out for both.
> >
> > Absolutely not!!! Please see above.
> >
> > > Before 7.0
> > > 3. the same concerns would be true to PREEMPT_VOLUNTARY and PREEMPT_NONE
> > > with PREEMPT_DYNAMIC=y.
> > > Those model never wanted a preemption, but PREEMPT_RCU could have
> > > forced a need_resched to be
> > > set. Which is also likely wrong. No?
> >
> > You lost me on this one. Please give me an explicit sequence of events
> > that would cause things to go wrong in this case.
>
> You are right. PREEMPT_RCU may set need_resched. But even then on
> none/voluntary
> schedule will not be called since static keys it cannot.
Whew!!! ;-)
Thanx, Paul
