On Mon, 24 Jul 2017 14:44:31 -0700 "Paul E. McKenney" <paul...@linux.vnet.ibm.com> wrote:
> The handling of RCU's no-CBs CPUs has a maintenance headache, namely > that if call_rcu() is invoked with interrupts disabled, the rcuo kthread > wakeup must be defered to a point where we can be sure that scheduler > locks are not held. Of course, there are a lot of code paths leading > from an interrupts-disabled invocation of call_rcu(), and missing any > one of these can result in excessive callback-invocation latency, and > potentially even system hangs. What about using irq_work? That's what perf and ftrace use for such a case. -- Steve > > This commit therefore uses a timer to guarantee that the wakeup will > eventually occur. If one of the deferred-wakeup points kicks in, then > the timer is simply cancelled. > > This commit also fixes up an incomplete removal of commits that were > intended to plug remaining exit paths, which should have the added > benefit of reducing the overhead of RCU's context-switch hooks. In > addition, it simplifies leader-to-follower callback-list handoff by > introducing locking. The call_rcu()-to-leader handoff continues to > use atomic operations in order to maintain good real-time latency for > common-case use of call_rcu(). >
