[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191211184416.GA6344@agluck-desk2.amr.corp.intel.com>
Date: Wed, 11 Dec 2019 10:44:16 -0800
From: "Luck, Tony" <tony.luck@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Andy Lutomirski <luto@...nel.org>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
David Laight <David.Laight@...lab.com>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
H Peter Anvin <hpa@...or.com>,
"Raj, Ashok" <ashok.raj@...el.com>,
"Shankar, Ravi V" <ravi.v.shankar@...el.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
x86 <x86@...nel.org>, Will Deacon <will@...nel.org>
Subject: Re: [PATCH v10 6/6] x86/split_lock: Enable split lock detection by
kernel parameter
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").
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. Split lock happens
because you can't keep ownership for two cache lines, so it gets
escalated to a bus lock.
-Tony
Powered by blists - more mailing lists