Re: [GIT PULL rcu/next] RCU commits for 4.13

[Linus Torvalds]

On Tue, Jun 27, 2017 at 1:58 PM, Paul E. McKenney
<paulmck@xxxxxxxxxxxxxxxxxx> wrote:
>
> So what next?
>
> One option would be to weaken the definition of spin_unlock_wait() so
> that it had acquire semantics but not release semantics.  Alternatively,
> we could keep the full empty-critical-section semantics and add memory
> barriers to spin_unlock_wait() implementations, perhaps as shown in the
> patch below.  I could go either way, though I do have some preference
> for the stronger semantics.
>
> Thoughts?

I would prefer to just say

 - document that spin_unlock_wait() has acquire semantics

 - mindlessly add the smp_mb() to all users

 - let users then decide if they are ok with just acquire

That's partly because I think we actually have *fewer* users than we
have implementations of spin_unlock_wait(). So adding a few smp_mb()'s
in the users is actually likely the smaller change.

But it's also because then that allows people who *can* say that
acquire is sufficient to just use it. People who use
spin_unlock_wait() tend to have some odd performance reason to do so,
so I think allowing them to use the more light-weight memory ordering
if it works for them is a good idea.

But finally, it's partly because I think "acquire" semantics are
actually the saner ones that we can explain the logic for much more
clearly.

Basically, acquire semantics means that you are guaranteed to see any
changes that were done inside a previously locked region.

Doesn't that sound like sensible semantics?

Then, the argument for "smp_mb()" (before the spin_unlock_wait()) becomes:

 - I did a write that will affect any future lock takes

 - the smp_mb() now means that that write will be ordered wrt the
acquire that guarantees we've seen all old actions taken by a lock.

Does those kinds of semantics make sense to people?

                Linus