lkml.org 
[lkml]   [2019]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2019-12-11 23:40    [W:0.184 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site