On Mon, Dec 16, 2013 at 04:45:39PM +0100, Peter Zijlstra wrote: > On Mon, Dec 16, 2013 at 07:32:48AM -0800, Paul E. McKenney wrote: > > On Mon, Dec 16, 2013 at 04:26:36PM +0100, Peter Zijlstra wrote: > > > On Mon, Dec 16, 2013 at 07:19:22AM -0800, tip-bot for Paul E. McKenney wrote: > > > > The underlying problem is that perf is invoking call_rcu() with the > > > > scheduler locks held, but in NOCB mode, call_rcu() will with high > > > > probability invoke the scheduler -- which just might want to use its > > > > locks. The reason that call_rcu() needs to invoke the scheduler is > > > > to wake up the corresponding rcuo callback-offload kthread, which > > > > does the job of starting up a grace period and invoking the callbacks > > > > afterwards. > > > > > > > > One solution (championed on a related problem by Lai Jiangshan) is to > > > > simply defer the wakeup to some point where scheduler locks are no longer > > > > held. Since we don't want to unnecessarily incur the cost of such > > > > deferral, the task before us is threefold: > > > > > > > > 1. Determine when it is likely that a relevant scheduler lock is held. > > > > > > > > 2. Defer the wakeup in such cases. > > > > > > > > 3. Ensure that all deferred wakeups eventually happen, preferably > > > > sooner rather than later. > > > > > > > > We use irqs_disabled_flags() as a proxy for relevant scheduler locks > > > > being held. This works because the relevant locks are always acquired > > > > with interrupts disabled. We may defer more often than needed, but that > > > > is at least safe. > > > > > > This would also allow us to do away with things like the below patch, > > > right? > > > > It takes care of one problem, but there are others, including > > rcu_read_unlock() inovking the scheduler to deboost itself. So for the > > moment, we still need the below patch. > > Oh right, see I knew I was forgetting something... :-) I am hoping to make your patch unnecessary, but it ain't trivial. ;-) We will get there! Especially if I can find Lai Jiangshan's old patch that reworked deboosting. :-/ Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html