[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160714193800.GN30154@twins.programming.kicks-ass.net>
Date: Thu, 14 Jul 2016 21:38:00 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
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 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.
Powered by blists - more mailing lists