openpower/atomics/discussion.mdwn

   1 # discussion moved here
   2
   3 moved here because the spec page itself must contain certainty
   4 rather than "undecided potential ideas"
   5
   6 the operations it has that I was going to propose:
   7
   8 * fetch_add
   9 * fetch_xor
  10 * fetch_or
  11 * fetch_and
  12 * fetch_umax
  13 * fetch_smax
  14 * fetch_umin
  15 * fetch_smin
  16 * exchange
  17
  18 as well as a few I wasn't going to propose (they seem less useful to me):
  19
  20 * compare-and-swap-not-equal
  21 * fetch-and-increment-bounded
  22 * fetch-and-increment-equal
  23 * fetch-and-decrement-bounded
  24 * store-twin
  25
  26 The spec also basically says that the atomic memory operations are only
  27 intended for when you want to do atomic operations on memory, but don't
  28 want that memory to be loaded into your L1 cache.
  29
  30 imho that restriction is specifically *not* wanted, because there are
  31 plenty of cases where atomic operations should happen in your L1 cache.
  32
  33 I'd guess that part of why those atomic operations weren't included in
  34 gcc or clang as the default implementation of atomic operations (when
  35 the appropriate ISA feature is enabled) is because of that restriction.
  36
  37 imho the cpu should be able to (but not required to) predict whether to
  38 send an atomic operation to L2-cache/L3-cache/etc./memory or to execute
  39 it directly in the L1 cache. The prediction could be based on how often
  40 that cache block was accessed from different cpus, e.g. by having a
  41 small saturating counter and a last-accessing-cpu field, where it would
  42 count how many times the same cpu accessed it in a row, sending it to the
  43 L1 cache if that's more than some limit, otherwise doing the operation
  44 in the L2/L3/etc.-cache if the limit wasn't reached or a different cpu
  45 tried to access it.