On Thu, Jun 21, 2018 at 1:49 AM, Paul E. McKenney <paul...@linux.vnet.ibm.com> wrote:
[...] > Perhaps the fact that there are architectures that can enter interrupt > handlers and never leave them when the CPU is non-idle. One example of > this is the usermode upcalls in the comment that you removed. > > Or have all the architectures been modified so that each and every call to > rcu_irq_enter() and to rcu_irq_exit() are now properly paired and nested? > > Proper nesting and pairing was -not- present in the past, hence the > special updates (AKA "crowbar") to the counters when transitioning to > and from idle. Thank you very much for explaining it in detail. > If proper nesting and pairing of rcu_irq_enter() and rcu_irq_exit() > is now fully in force across all architectures and configurations, the > commit log needs to say this, preferably pointing to the corresponding > commits that made this change. Right. > There is a call to rcu_irq_enter() without a corresponding call to > rcu_irq_exit(), so that the ->dynticks_nesting counter never goes back to > zero so that the next time this CPU goes idle, RCU thinks that the CPU > is still non-idle. This can result in excessively long grace periods > and needless IPIs to idle CPUs. No doubt. > But only if calls to rcu_irq_enter() and rcu_irq_exit() are now always > properly paired and nested, which was definitely -not- the case last > I looked. I missed it. Right. It's worth only in the case that calls to rcu_irq_enter() and rcu_irq_exit() are always properly paired and nested. > OK, so I can further consider this pair of patches only if > all architectures now properly pair and nest rcu_irq_enter() and > rcu_irq_exit(). It would be very good if they did, but actually testing > back in the day showed that they did not. If that has changed, that > would be a very good thing, but if not, this patch injects bugs. Totally agree with you. Sorry bothering you. -- Thanks, Byungchul