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

Hi Paul. Thanks for taking time looking into this.

quoted

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.

quoted

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.

quoted

                                        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.

quoted

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.