linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott Wood <swood@redhat.com>
To: paulmck@linux.ibm.com
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Juri Lelli <juri.lelli@redhat.com>,
	Clark Williams <williams@redhat.com>,
	linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH RT 3/4] rcu: unlock special: Treat irq and preempt disabled the same
Date: Thu, 20 Jun 2019 18:08:19 -0500	[thread overview]
Message-ID: <5d24d1243849d9f8f6884348e1ceafcc3b7314fd.camel@redhat.com> (raw)
In-Reply-To: <20190620222505.GB26519@linux.ibm.com>

On Thu, 2019-06-20 at 15:25 -0700, Paul E. McKenney wrote:
> On Thu, Jun 20, 2019 at 04:59:30PM -0500, Scott Wood wrote:
> > On Thu, 2019-06-20 at 14:10 -0700, Paul E. McKenney wrote:
> > > On Tue, Jun 18, 2019 at 08:19:07PM -0500, Scott Wood wrote:
> > > > [Note: Just before posting this I noticed that the invoke_rcu_core
> > > > stuff
> > > >  is part of the latest RCU pull request, and it has a patch that
> > > >  addresses this in a more complicated way that appears to deal with
> > > > the
> > > >  bare irq-disabled sequence as well.
> > > 
> > > Far easier to deal with it than to debug the lack of it.  ;-)
> > > 
> > > >  Assuming we need/want to support such sequences, is the
> > > >  invoke_rcu_core() call actually going to result in scheduling any
> > > >  sooner?  resched_curr() just does the same setting of need_resched
> > > >  when it's the same cpu.
> > > > ]
> > > 
> > > Yes, invoke_rcu_core() can in some cases invoke the scheduler sooner.
> > > Setting the CPU-local bits might not have effect until the next
> > > interrupt.
> > 
> > Maybe I'm missing something, but I don't see how (in the non-use_softirq
> > case).  It just calls wake_up_process(), which in resched_curr() will
> > set
> > need_resched but not do an IPI-to-self.
> 
> The common non-rt case will be use_softirq.  Or are you referring
> specifically to this block of code in current -rcu?
> 
> 		} else if (exp && irqs_were_disabled && !use_softirq &&
> 			   !t->rcu_read_unlock_special.b.deferred_qs) {
> 			// Safe to awaken and we get no help from enabling
> 			// irqs, unlike bh/preempt.
> 			invoke_rcu_core();

Yes, that one.  If that block is removed the else path should be sufficient,
now that an IPI-to-self has been added.

Also, shouldn't the IPI-to-self be conditioned on irqs_were_disabled? 
Besides that being the problem the IPI was meant to address, if irqs are
enabled the IPI is likely to happen before preempt is re-enabled and thus it
won't accomplish anything.

-Scott



  reply	other threads:[~2019-06-20 23:08 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-19  1:19 [PATCH RT 0/4] Address rcutorture issues Scott Wood
2019-06-19  1:19 ` [PATCH RT 1/4] rcu: Acquire RCU lock when disabling BHs Scott Wood
2019-06-20 20:53   ` Paul E. McKenney
2019-06-20 21:06     ` Scott Wood
2019-06-20 21:20       ` Paul E. McKenney
2019-06-20 21:38         ` Scott Wood
2019-06-20 22:16           ` Paul E. McKenney
2019-06-19  1:19 ` [PATCH RT 2/4] sched: migrate_enable: Use sleeping_lock to indicate involuntary sleep Scott Wood
2019-06-19  1:19 ` [RFC PATCH RT 3/4] rcu: unlock special: Treat irq and preempt disabled the same Scott Wood
2019-06-20 21:10   ` Paul E. McKenney
2019-06-20 21:59     ` Scott Wood
2019-06-20 22:25       ` Paul E. McKenney
2019-06-20 23:08         ` Scott Wood [this message]
2019-06-22  0:26           ` Paul E. McKenney
2019-06-22 19:13             ` Paul E. McKenney
2019-06-24 17:40               ` Scott Wood
2019-06-19  1:19 ` [RFC PATCH RT 4/4] rcutorture: Avoid problematic critical section nesting Scott Wood
2019-06-20 21:18   ` Paul E. McKenney
2019-06-20 21:43     ` Scott Wood
2019-06-21 16:38     ` Sebastian Andrzej Siewior
2019-06-21 23:59       ` Paul E. McKenney
2019-06-26 15:08         ` Steven Rostedt
2019-06-26 16:49           ` Scott Wood
2019-06-27 18:00             ` Paul E. McKenney
2019-06-27 20:16               ` Scott Wood
2019-06-27 20:50                 ` Paul E. McKenney
2019-06-27 22:46                   ` Scott Wood
2019-06-28  0:52                     ` Paul E. McKenney
2019-06-28 19:37                       ` Scott Wood
2019-06-28 20:24                         ` Paul E. McKenney
2019-06-20 19:12 ` [PATCH RT 0/4] Address rcutorture issues Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5d24d1243849d9f8f6884348e1ceafcc3b7314fd.camel@redhat.com \
    --to=swood@redhat.com \
    --cc=bigeasy@linutronix.de \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=paulmck@linux.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=williams@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).