From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
jiangshanlai@gmail.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com,
fweisbec@gmail.com, oleg@redhat.com
Subject: Re: [PATCH RFC tip/core/rcu 1/2] rcu: Defer reporting RCU-preempt quiescent states when disabled
Date: Sun, 1 Jul 2018 20:03:13 -0700 [thread overview]
Message-ID: <20180702030313.GH3593@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180702003732.GB95395@joelaf.mtv.corp.google.com>
On Sun, Jul 01, 2018 at 05:37:32PM -0700, Joel Fernandes wrote:
> On Sun, Jul 01, 2018 at 03:25:01PM -0700, Paul E. McKenney wrote:
> [...]
> > > > @@ -602,6 +589,66 @@ static void rcu_read_unlock_special(struct task_struct *t)
> > > > }
> > > > }
> > > >
> > > > +/*
> > > > + * Is a deferred quiescent-state pending, and are we also not in
> > > > + * an RCU read-side critical section? It is the caller's responsibility
> > > > + * to ensure it is otherwise safe to report any deferred quiescent
> > > > + * states. The reason for this is that it is safe to report a
> > > > + * quiescent state during context switch even though preemption
> > > > + * is disabled. This function cannot be expected to understand these
> > > > + * nuances, so the caller must handle them.
> > > > + */
> > > > +static bool rcu_preempt_need_deferred_qs(struct task_struct *t)
> > > > +{
> > > > + return (this_cpu_ptr(&rcu_preempt_data)->deferred_qs ||
> > > > + READ_ONCE(t->rcu_read_unlock_special.s)) &&
> > > > + !t->rcu_read_lock_nesting;
> > > > +}
> > > > +
> > > > +/*
> > > > + * Report a deferred quiescent state if needed and safe to do so.
> > > > + * As with rcu_preempt_need_deferred_qs(), "safe" involves only
> > > > + * not being in an RCU read-side critical section. The caller must
> > > > + * evaluate safety in terms of interrupt, softirq, and preemption
> > > > + * disabling.
> > > > + */
> > > > +static void rcu_preempt_deferred_qs(struct task_struct *t)
> > > > +{
> > > > + unsigned long flags;
> > > > +
> > > > + if (!rcu_preempt_need_deferred_qs(t))
> > > > + return;
> > > > + local_irq_save(flags);
> > > > + rcu_preempt_deferred_qs_irqrestore(t, flags);
> > > > +}
> > > > +
> > > > +/*
> > > > + * Handle special cases during rcu_read_unlock(), such as needing to
> > > > + * notify RCU core processing or task having blocked during the RCU
> > > > + * read-side critical section.
> > > > + */
> > > > +static void rcu_read_unlock_special(struct task_struct *t)
> > > > +{
> > > > + unsigned long flags;
> > > > + bool preempt_bh_were_disabled = !!(preempt_count() & ~HARDIRQ_MASK);
> > >
> > > Would it be better to just test for those bits just to be safe the higher
> > > order bits don't bleed in, such as PREEMPT_NEED_RESCHED, something like the
> > > following based on the 'dev' branch?
> >
> > Good point! My plan is to merge it into the original commit with
> > attribution. Please let me know if you have objections.
> >
>
> Sure! That sounds good to me.
Very good, I now have a "squash" commit queued, thank you!
Thanx, Paul
next prev parent reply other threads:[~2018-07-02 3:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-27 20:48 [PATCH RFC tip/core/rcu 0/2] RCU consolidation patches Paul E. McKenney
2018-06-27 20:49 ` [PATCH RFC tip/core/rcu 1/2] rcu: Defer reporting RCU-preempt quiescent states when disabled Paul E. McKenney
2018-07-01 17:40 ` Joel Fernandes
2018-07-01 22:25 ` Paul E. McKenney
2018-07-02 0:37 ` Joel Fernandes
2018-07-02 3:03 ` Paul E. McKenney [this message]
2018-07-01 18:38 ` Joel Fernandes
2018-07-01 22:27 ` Paul E. McKenney
2018-07-02 0:35 ` Joel Fernandes
2018-07-02 3:11 ` Paul E. McKenney
2018-07-02 4:49 ` Joel Fernandes
2018-07-02 13:02 ` Paul E. McKenney
2018-07-04 6:43 ` [lkp-robot] [rcu] e46874dd99: WARNING:suspicious_RCU_usage kernel test robot
2018-07-04 6:43 ` kernel test robot
2018-07-04 11:47 ` Paul E. McKenney
2018-07-04 11:47 ` Paul E. McKenney
2018-06-27 20:49 ` [PATCH RFC tip/core/rcu 2/2] rcutorture: Handle extended "rcu" read-side critical sections 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=20180702030313.GH3593@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.