Messages in this thread | | | From | Linus Torvalds <> | Date | Tue, 27 Jun 2017 14:48:18 -0700 | Subject | Re: [GIT PULL rcu/next] RCU commits for 4.13 |
| |
On Tue, Jun 27, 2017 at 1:58 PM, Paul E. McKenney <paulmck@linux.vnet.ibm.com> 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
| |