On Wed, Oct 28, 2020 at 01:15:54PM -0700, Paul E. McKenney wrote: > On Wed, Oct 28, 2020 at 09:02:43PM +0100, Peter Zijlstra wrote:
> > Subject: rcu/tree: Use irq_work_queue_remote() > > From: Peter Zijlstra <pet...@infradead.org> > > Date: Wed Oct 28 11:53:40 CET 2020 > > > > All sites that consume rcu_iw_gp_seq seem to have rcu_node lock held, > > so setting it probably should too. Also the effect of self-IPI here > > would be setting rcu_iw_gp_seq to the value we just set it to > > (pointless) and clearing rcu_iw_pending, which we just set, so don't > > set it. > > > > Passes TREE01. > > > > Signed-off-by: Peter Zijlstra (Intel) <pet...@infradead.org> > > --- > > kernel/rcu/tree.c | 10 ++++++---- > > 1 file changed, 6 insertions(+), 4 deletions(-) > > > > --- a/kernel/rcu/tree.c > > +++ b/kernel/rcu/tree.c > > @@ -1308,14 +1308,16 @@ static int rcu_implicit_dynticks_qs(stru > > resched_cpu(rdp->cpu); > > WRITE_ONCE(rdp->last_fqs_resched, jiffies); > > } > > -#ifdef CONFIG_IRQ_WORK > > + raw_spin_lock_rcu_node(rnp); > > The caller of rcu_implicit_dynticks_qs() already holds this lock. > Please see the force_qs_rnp() function and its second call site, > to which rcu_implicit_dynticks_qs() is passed as an argument. > > But other than that, this does look plausible. And getting rid of > that #ifdef is worth something. ;-) Dang, clearly TREE01 didn't actually hit any of this code :/ Is there another test I should be running?
