[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170116210111.GP5238@linux.vnet.ibm.com>
Date: Mon, 16 Jan 2017 13:01:11 -0800
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-kernel@...r.kernel.org, mingo@...nel.org,
jiangshanlai@...il.com, dipankar@...ibm.com,
akpm@...ux-foundation.org, mathieu.desnoyers@...icios.com,
josh@...htriplett.org, tglx@...utronix.de, rostedt@...dmis.org,
dhowells@...hat.com, edumazet@...gle.com, dvhart@...ux.intel.com,
fweisbec@...il.com, oleg@...hat.com, bobby.prani@...il.com
Subject: Re: [PATCH tip/core/rcu 3/6] rcu: Abstract dynticks extended
quiescent state enter/exit operations
On Mon, Jan 16, 2017 at 05:43:37PM +0100, Peter Zijlstra wrote:
> On Sat, Jan 14, 2017 at 12:54:42AM -0800, Paul E. McKenney wrote:
> > /*
> > + * Record entry into an extended quiescent state. This is only to be
> > + * called when not already in an extended quiescent state.
> > + */
> > +static void rcu_dynticks_eqs_enter(void)
> > +{
> > + struct rcu_dynticks *rdtp = this_cpu_ptr(&rcu_dynticks);
> > +
> > + /*
> > + * CPUs seeing atomic_inc() must see prior RCU read-side critical
> > + * sections, and we also must force ordering with the next idle
> > + * sojourn.
> > + */
> > + smp_mb__before_atomic(); /* See above. */
> > + atomic_inc(&rdtp->dynticks);
> > + smp_mb__after_atomic(); /* See above. */
> > + WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) &&
> > + atomic_read(&rdtp->dynticks) & 0x1);
> > +}
>
> In an earlier patch you replaced things with atomic_add_return(), why
> not use atomic_inc_return() here?
The rationale is that the earlier patch uses the return value
unconditionally, while at this site, the return value would be used only
if CONFIG_RCU_EQS_DEBUG. But mostly inertia.
Thanx, Paul
Powered by blists - more mailing lists