On Fri, Jul 13, 2018 at 2:34 AM Will Deacon <will.dea...@arm.com> wrote:
>
> And, since we're stating preferences, I'll reiterate my preference towards:
>
> * RCsc unlock/lock
> * RCpc release/acquire
Yes, I think this would be best. We *used* to have pretty heavy-weight
locking rules for various reasons, and we relaxed them for reasons
that weren't perhaps always the right ones.
Locking is pretty heavy-weight in general, and meant to be the "I
don't really have to think about this very much" option. Then not
being serializing enough to confuse people when it allows odd behavior
(on _some_ architectures) does not sound like a great idea.
In contrast, when you do release/acquire or any of the other "I know
what I'm doing" things, I think we want the minimal serialization
implied by the very specialized op.
> * Not fussed about atomic rmws, but having them closer to RCsc would
> make it easier to implement and reason about generic locking
> implementations
I would prefer that rmw's be RCsc by default, but that there are then
"relaxed" versions of it that aren't.
For example, one common case of rmw has nothing to do with any
ordering at all: statistics gathering. It usually has absolutely zero
need for any ordering per se, and all it wants is cache coherence.
Yes, yes, the really crticial stuff we then use percpu counters for
and a lot of clever software, but there's a lot of cases where that
isn't practical or isn't _quite_ important enough.
So "atomic_add()" being RCsc sounds like a nice tight requirement, but
then architectures who can do it cheaper could have
"atomic_add_relaxed()" that has no inherent ordering at all.
But let's see what the powerpc people find about the actual
performance impact of being RCsc on locking. Real numbers for real
loads would be nice.
Linus
