From ec763621c66b0e51793e638e9d15c7843c47d633 Mon Sep 17 00:00:00 2001 From: lkcl Date: Fri, 8 Jul 2022 20:01:59 +0100 Subject: [PATCH] --- openpower/atomics/discussion.mdwn | 45 +++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 openpower/atomics/discussion.mdwn diff --git a/openpower/atomics/discussion.mdwn b/openpower/atomics/discussion.mdwn new file mode 100644 index 000000000..050e83458 --- /dev/null +++ b/openpower/atomics/discussion.mdwn @@ -0,0 +1,45 @@ +# discussion moved here + +moved here because the spec page itself must contain certainty +rather than "undecided potential ideas" + +the operations it has that I was going to propose: + +* fetch_add +* fetch_xor +* fetch_or +* fetch_and +* fetch_umax +* fetch_smax +* fetch_umin +* fetch_smin +* exchange + +as well as a few I wasn't going to propose (they seem less useful to me): + +* compare-and-swap-not-equal +* fetch-and-increment-bounded +* fetch-and-increment-equal +* fetch-and-decrement-bounded +* store-twin + +The spec also basically says that the atomic memory operations are only +intended for when you want to do atomic operations on memory, but don't +want that memory to be loaded into your L1 cache. + +imho that restriction is specifically *not* wanted, because there are +plenty of cases where atomic operations should happen in your L1 cache. + +I'd guess that part of why those atomic operations weren't included in +gcc or clang as the default implementation of atomic operations (when +the appropriate ISA feature is enabled) is because of that restriction. + +imho the cpu should be able to (but not required to) predict whether to +send an atomic operation to L2-cache/L3-cache/etc./memory or to execute +it directly in the L1 cache. The prediction could be based on how often +that cache block was accessed from different cpus, e.g. by having a +small saturating counter and a last-accessing-cpu field, where it would +count how many times the same cpu accessed it in a row, sending it to the +L1 cache if that's more than some limit, otherwise doing the operation +in the L2/L3/etc.-cache if the limit wasn't reached or a different cpu +tried to access it. -- 2.30.2