Messages in this thread | | | Date | Wed, 11 Dec 2019 23:39:17 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH v10 6/6] x86/split_lock: Enable split lock detection by kernel parameter |
| |
On Wed, Dec 11, 2019 at 10:44:16AM -0800, Luck, Tony wrote: > On Wed, Dec 11, 2019 at 06:52:02PM +0100, Peter Zijlstra wrote: > > Sure, but we're talking two cpus here. > > > > u32 var = 0; > > u8 *ptr = &var; > > > > CPU0 CPU1 > > > > xchg(ptr, 1) > > > > xchg((ptr+1, 1); > > r = READ_ONCE(var); > > It looks like our current implementation of set_bit() would already run > into this if some call sites for a particular bitmap `pass in constant > bit positions (which get optimized to byte wide "orb") while others pass > in a variable bit (which execute as 64-bit "bts").
Yes, but luckily most nobody cares.
I only know of two places in the entire kernel where we considered this, one is clear_bit_unlock_is_negative_byte() and there we punted and stuffed everything in a single byte, and the other is that x86 queued_fetch_set_pending_acquire() thing I pointed out earlier.
> I'm not a h/w architect ... but I've assumed that a LOCK operation > on something contained entirely within a cache line gets its atomicity > by keeping exclusive ownership of the cache line.
Right, but like I just wrote to Andy, consider SMT where each thread has its own store-buffer. Then the line is local to the core, but there still is a remote sb to hide stores in.
I don't know if anything x86 does that, or even allows that, but I'm not aware of specs that are clear enough to say either way.
| |