lkml.org 
[lkml]   [2013]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tip:core/rcu] rcu: Break call_rcu() deadlock involving scheduler and perf
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... :-)


\
 
 \ /
  Last update: 2013-12-16 18:01    [W:1.224 / U:0.684 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site