[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <C2D7FE5348E1B147BCA15975FBA23075665A55A0@IN01WEMBXB.internal.synopsys.com>
Date: Fri, 12 Jun 2015 13:16:27 +0000
From: Vineet Gupta <Vineet.Gupta1@...opsys.com>
To: Peter Zijlstra <peterz@...radead.org>
CC: "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"arc-linux-dev@...opsys.com" <arc-linux-dev@...opsys.com>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH v2] ARC: add smp barriers around atomics per
Documentation/atomic_ops.txt
On Friday 12 June 2015 06:35 PM, Peter Zijlstra wrote:
On Fri, Jun 12, 2015 at 05:45:59PM +0530, Vineet Gupta wrote:
> - arch_spin_lock/unlock were lacking the ACQUIRE/RELEASE barriers
> Since ARCv2 only provides load/load, store/store and all/all, we need
> the full barrier
>
> - LLOCK/SCOND based atomics, bitops, cmpxchg, which return modified
> values were lacking the explicit smp barriers.
>
> - Non LLOCK/SCOND varaints don't need the explicit barriers since that
> is implicity provided by the spin locks used to implement the
> critical section (the spin lock barriers in turn are also fixed in
> this commit as explained above
And iirc you're relying on asm-generic/barrier.h to issue
smp_mb__{before,after}_atomic() as smp_mb(), right?
Yep !
Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org><mailto:peterz@...radead.org>
Thx !
Although I'd love to know why you need those extra barriers in your
spinlocks...
I'll keep you posted as I'd like to get rid of them too. But there's bunch of stuff going on ATM so can't really jump into investigating that. Will need some wrestling with perf... which makes me think that I'd posted a bunch of perf patches for ARC/ARCv2 as well - can u please take alook at them sometime soon !
Thx,
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists