Hi Michael, On Wed, Mar 02, 2022 at 07:58:33AM -0500, Michael S. Tsirkin wrote: > > There's also the atomicity aspect, which I think makes your benchmark > > not quite accurate. Those 16 bytes could change between the first and > > second word (or between the Nth and N+1th word for N<=3 on 32-bit). > > What if in that case the word you read second doesn't change, but the > > word you read first did? So then you find yourself having to do a > > hi-lo-hi dance. > > And then consider the 32-bit case, where that's even > > more annoying. This is just one of those things that comes up when you > > compare the semantics of a "large unique ID" and "word-sized counter", > > as general topics. (My suggestion is that vmgenid provide both.) > > I don't see how this matters for any applications at all. Feel free to > present a case that would be race free with a word but not a 16 > byte value, I could not imagine one. It's human to err of course. Word-size reads happen all at once on systems that Linux supports, whereas this is not the case for 16 bytes (with a few niche exceptions like cmpxchg16b and such). If you read the counter atomically, you can check to see whether it's changed just after encrypting but before transmitting and not transmit if it has changed, and voila, no race. With 16 bytes, synchronization of that read is pretty tricky (though maybe not all together impossible), because, as I mentioned, the first word might have changed by the time you read a matching second word. I'm sure you're familiar with the use of seqlocks in the kernel for solving a somewhat related problem. Jason
