[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170918162412.GM3521@linux.vnet.ibm.com>
Date: Mon, 18 Sep 2017 09:24:12 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Neeraj Upadhyay <neeraju@...eaurora.org>, josh@...htriplett.org,
mathieu.desnoyers@...icios.com, jiangshanlai@...il.com,
linux-kernel@...r.kernel.org, sramana@...eaurora.org,
prsood@...eaurora.org, pkondeti@...eaurora.org,
markivx@...eaurora.org, peterz@...radead.org
Subject: Re: Query regarding synchronize_sched_expedited and resched_cpu
On Mon, Sep 18, 2017 at 12:12:13PM -0400, Steven Rostedt wrote:
> On Mon, 18 Sep 2017 09:01:25 -0700
> "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com> wrote:
>
>
> > sched: Make resched_cpu() unconditional
> >
> > The current implementation of synchronize_sched_expedited() incorrectly
> > assumes that resched_cpu() is unconditional, which it is not. This means
> > that synchronize_sched_expedited() can hang when resched_cpu()'s trylock
> > fails as follows (analysis by Neeraj Upadhyay):
> >
> > o CPU1 is waiting for expedited wait to complete:
> > sync_rcu_exp_select_cpus
> > rdp->exp_dynticks_snap & 0x1 // returns 1 for CPU5
> > IPI sent to CPU5
> >
> > synchronize_sched_expedited_wait
> > ret = swait_event_timeout(
> > rsp->expedited_wq,
> > sync_rcu_preempt_exp_done(rnp_root),
> > jiffies_stall);
> >
> > expmask = 0x20 , and CPU 5 is in idle path (in cpuidle_enter())
> >
> > o CPU5 handles IPI and fails to acquire rq lock.
> >
> > Handles IPI
> > sync_sched_exp_handler
> > resched_cpu
> > returns while failing to try lock acquire rq->lock
> > need_resched is not set
> >
> > o CPU5 calls rcu_idle_enter() and as need_resched is not set, goes to
> > idle (schedule() is not called).
> >
> > o CPU 1 reports RCU stall.
> >
> > Given that resched_cpu() is used only by RCU, this commit fixes the
> > assumption by making resched_cpu() unconditional.
>
> Probably want to run this with several workloads with lockdep enabled
> first.
As soon as I work through the backlog of lockdep complaints that
appeared in the last merge window... :-(
sparse_irq_lock, I am looking at you!!! ;-)
Thanx, Paul
Powered by blists - more mailing lists