Re: [PATCH v4 1/1] powerpc: enable dynamic preemption

[Shrikanth Hegde]

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.

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

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