lkml.org 
[lkml]   [2015]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 18/28] ARC: add smp barriers around atomics per memory-barrriers.txt
    Date
    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


    \
     
     \ /
      Last update: 2015-06-11 15:41    [W:3.007 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site