On Mon, Nov 11, 2019 at 01:15:16PM -0500, Mouse wrote: > > Uninterruptible means exactly that, there is a clear before and after > > state and no interrupts can happen in between. > > Is uninterruptible all you care about? Or does it also need to be > atomic with respect to other CPUs? Eventually, of course, you'll want > all those counter values on a single CPU - does that happen often > enough to matter? > > Also, does it actually need to be uninterruptible, or does it just need > to be interrupt-tolerant? I'm not as clear as I'd like on what the > original desire here was, so I'm not sure but that we might be trying > to solve a harder problem than necessary.
The update needs to be uninterruptable on the local CPU in the sense that context switches and interrupts don't tear the R and W part of the RMW cycle apart. x86 ALU instructions with memory operand as destination fit the bill fine. It doesn't have to be atomic, no other CPU is supposed to write to that cache line. It also generally doesn't matter whether they see the old OR the new value, as long as it is either. We have full control over alignment. Joerg