[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20160714195434.GZ7094@linux.vnet.ibm.com>
Date: Thu, 14 Jul 2016 12:54:34 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Oleg Nesterov <oleg@...hat.com>, mingo@...nel.org,
linux-kernel@...r.kernel.org, tj@...nel.org,
john.stultz@...aro.org, dimitrysh@...gle.com, romlem@...gle.com,
ccross@...gle.com, tkjos@...gle.com
Subject: Re: [PATCH 2/2] locking/percpu-rwsem: Introduce bias knob
On Thu, Jul 14, 2016 at 09:38:00PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 14, 2016 at 12:29:59PM -0700, Paul E. McKenney wrote:
> > On Thu, Jul 14, 2016 at 09:20:18PM +0200, Peter Zijlstra wrote:
> > > /**
> > > + * rcu_sync_sabotage() - Sabotage a fresh rcu_sync instance
> > > + * @rsp: Pointer to rcu_sync structure to be sabotaged
> > > + *
> > > + * Must be called after rcu_sync_init() and before first use.
> > > + *
> > > + * Ensures rcu_sync_is_idle() returns false and rcu_sync_{enter,exit}() pairs
> > > + * turn into NO-OPs.
> > > + */
> > > +void rcu_sync_sabotage(struct rcu_sync *rsp)
> > > +{
> > > + rsp->gp_count++;
> > > + rsp->gp_state = !GP_IDLE;
> >
> > ??? A very strange way to say GP_PENDING. A new GP_DISABLED, perhaps?
>
> Right, so the important thing is that its not GP_IDLE, the rest doesn't
> really matter.
>
> This forces rcu_sync_is_idle() to return false. The skewed gp_count
> ensures rcu_sync_{enter,exit}() pairs no-op.
Understood. But let's have at least some pity on the poor people who
might one day read this code.
Thanx, Paul
Powered by blists - more mailing lists