Re: [PATCH 18/28] ARC: add smp barriers around atomics per memory-barrriers.txt

[Vineet Gupta]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/