On Wednesday 10 June 2015 04:23 PM, Peter Zijlstra wrote:
> On Wed, Jun 10, 2015 at 09:17:16AM +0000, Vineet Gupta wrote:
>> I wanted to clarify a couple of things
>> (1) ACQUIRE barrier implies store/{store,load} while RELEASE implies
>> {load,store}/store and given what DMB provides for ARCv2, smp_mb() is the
>> only fit ?
> Please see Documentation/memory-barriers.txt, but a quick recap:
>
> - ACQUIRE: both loads and stores before to the barrier are allowed to
> be observed after it. Neither loads nor stores after the barrier are
> allowed to be observed before it.
>
> - RELEASE: both loads and stores before it must be observed before the
> barrier. However, any load or store after it may be observed before
> it.
>
> Therefore:
>
> X = Y = 0;
>
> [S] X = 1
> ACQUIRE
>
> RELEASE
> [S] Y = 1
>
> is in fact fully unordered, because both stores are allowed to cross in,
> and could cross one another on the inside, like:
>
> ACQUIRE
> [S] Y = 1
> [S] X = 1
> RELEASE
Thx for that. I think I was mixing smp_load_acquire() / store_release() with
the
spin lock ACQUIRE/RELEASE. As Paul put it on a lwn article, after re-reading
memory-barrier.txt I've indeed felt a hit on my already meager brain power :-)
>> (2) Do we need smp_mb() on both sides of spin lock/unlock - doesn't ACQUIRE
>> imply
>> we have a smp_mb() after lock but before any subsequent critical section -
>> so the
>> top hunk is not necessarily needed. Similarly RELEASE requires a smp_mb()
>> before
>> the memory operation for lock, but not after.
> You do not need an smp_mb() on both sides, as you say, after lock and
> before unlock is sufficient. The main point being that things can not
> escape out of the critical section. Its fine for them to leak in.
Ok - neverthless I will probably keep the extraneous barriers around for now
since
I see some weird hackbench regression on a dual core SMP build by removing the
those 3 barriers (and/or replacing them with a nop so as to keep the icache /
bpu
micro-arch profile exactly same as before).
-Vineet
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
