LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: paulmck@linux.vnet.ibm.com, peterz@infradead.org
Cc: torvalds@linux-foundation.org, oleg@redhat.com,
	benh@kernel.crashing.org, linux-kernel@vger.kernel.org,
	linux-arch@vger.kernel.org
Subject: Behaviour of smp_mb__{before,after}_spin* and acquire/release
Date: Tue, 13 Jan 2015 16:33:54 +0000	[thread overview]
Message-ID: <20150113163353.GE31784@arm.com> (raw)

Hi Paul,

I started dusting off a series I've been working to implement a relaxed
atomic API in Linux (i.e. things like atomic_read(v, ACQUIRE)) but I'm
having trouble making sense of the ordering semantics we have in mainline
today:

  1. Does smp_mb__before_spinlock actually have to order prior loads
     against later loads and stores? Documentation/memory-barriers.txt
     says it does, but that doesn't match the comment (or implementation)
     in include/linux/spinlock.h

  2. Does smp_mb__after_unlock_lock order smp_store_release against
     smp_load_acquire? Again, Documentation/memory-barriers.txt puts
     these operations into the RELEASE and ACQUIRE classes respectively,
     but since smp_mb__after_unlock_lock is a NOP everywhere other than
     PowerPC, I don't think this is enforced by the current code. Most
     architectures follow the pattern used by asm-generic/barrier.h:

       release: smp_mb(); STORE
       acquire: LOAD; smp_mb();

     which doesn't provide any release -> acquire ordering afaict.

My plan for the atomics was to add acquire, release, acquire + release
and unordered variants, where the acquire/release semantics would
actually be sequentially consistent. That allows us to implement the
existing atomics easily in terms of the new API, but it's different
to what we're doing for the smp_load_acquire and smp_store_release
functions above.

Cheers,

Will

             reply	other threads:[~2015-01-13 16:34 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-13 16:33 Will Deacon [this message]
2015-01-13 18:45 ` Oleg Nesterov
2015-01-14 11:31   ` Will Deacon
2015-01-20  3:40     ` Paul E. McKenney
2015-01-20 10:43       ` Will Deacon
2015-01-20  9:34 ` Peter Zijlstra
2015-01-20 10:38   ` Will Deacon
2015-01-20 21:35   ` Paul E. McKenney
2015-01-21 13:56     ` Will Deacon
2015-01-23 14:08     ` Will Deacon
2015-01-23 21:21       ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150113163353.GE31784@arm.com \
    --to=will.deacon@arm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --subject='Re: Behaviour of smp_mb__{before,after}_spin* and acquire/release' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).