Intel Bus Lock Detection Merged For Linux 5.13

[phoronix]

Phoronix: Intel Bus Lock Detection Merged For Linux 5.13

Intel's code for Linux kernel bus lock detection that works in conjunction with newer Intel CPUs has landed in the Linux kernel...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.13-Lands-Intel-Bus-Lock

[cewbdex]

Which are "newer" CPUs?

[coder]

Which are "newer" CPUs?

Ugh. New enough that the CPUID references I checked still show that bit as RESERVED. Intel docs should say, but I can't be bothered to find those and search them for the sake of idle curiosity.

Anyway, it's safe to assume we're talking about one of the 10 nm CPUs.

[coder]

Anyway, the description in the article did more to confuse than inform me, so I checked the patch and here's the most enlightening part of the description:

Newer CPUs provide a second mechanism to detect operations with lock
prefix which go accross a cache line boundary. Such operations have to
take bus lock which causes a system wide performance degradation when
these operations happen frequently.

The new mechanism is not using the #AC exception. It triggers #DB and is
restricted to operations in user space. Kernel side split lock access can
only be detected by the #AC based variant. Contrary to the #AC based
mechanism the #DB based variant triggers _after_ the instruction was
executed. The mechanism is CPUID enumerated and contrary to the #AC
version which is based on the magic TEST_CTRL_MSR and model/family based
enumeration on the way to become architectural.

The #DB feature is referring to:

#define X86_FEATURE_BUS_LOCK_DETECT (16*32+24) /* Bus Lock detect */

...which is easier to find, if you know that it's just 10 bits above VPOPCNTDQ (which all the CPUID references I checked did have).

[coder]

BTW, for those who are still in the dark. "operations with lock prefix which go across a cache line boundary" is referring to a CPU instruction that performs some sort of read-modify-write operation that cannot be interrupted, such as atomically adding 1 to the value at a certain memory address. These form the basis of thread synchronization, in multiprocessor systems, and their efficiency increasingly affects system performance, as CPU core counts scale ever higher.

A split-lock happens when the data being operated on, by one of these instructions, isn't entirely contained within a single cacheline. When that happens, the CPU core executing the instruction has to do additional work to get & hold exclusive ownership of both cachelines. The suggestion of a "bus lock" implies that it blocks memory bus operations on other cores, as well, which could be seriously detrimental to overall system performance.

In newer CPU ISAs (e.g. AArch64, RISC V), they could take the view that this is illegal and avoid having to handle it by just forcing your program to crash. However, because some older x86 CPUs allowed it, newer ones would break coveted backwards-compatibility if they didn't support it.

Sorry if I oversimplified anything. I hope that helps someone.

[Jumbotron]

BTW, for those who are still in the dark. "operations with lock prefix which go across a cache line boundary" is referring to a CPU instruction that performs some sort of read-modify-write operation that cannot be interrupted, such as atomically adding 1 to the value at a certain memory address. These form the basis of thread synchronization, in multiprocessor systems, and their efficiency increasingly affects system performance, as CPU core counts scale ever higher.

A split-lock happens when the data being operated on, by one of these instructions, isn't entirely contained within a single cacheline. When that happens, the CPU core executing the instruction has to do additional work to get & hold exclusive ownership of both cachelines. The suggestion of a "bus lock" implies that it blocks memory bus operations on other cores, as well, which could be seriously detrimental to overall system performance.

In newer CPU ISAs (e.g. AArch64, RISC V), they could take the view that this is illegal and avoid having to handle it by just forcing your program to crash. However, because some older x86 CPUs allowed it, newer ones would break coveted backwards-compatibility if they didn't support it.

Sorry if I oversimplified anything. I hope that helps someone.

That's a very nice, concise and easy to understand explanation. Honestly, thank you for that.

I'm not surprised at all to see such a thing be engineered for x86 particularly for "backward compatubility". x86 along with Windows are old, legacy tech hobbled by big firms still stuck with code from the 80s and an operational mentality to boot that needs such backwards compatibility. Thank God _ or insert diety or no diety of choice_a lot if not most of that crap is being shunted to a container and run on an ARM based cloud such as AWS or Google. Still, though, too many on prem servers needing legacy x86 cores to run legacy software still exists.

As far as your observation that as far as "new Intel cpus" having this split lock probably being "10nm" cpus is also probably correct. Which means...<chuckle>...it's not that many Intel cpus.

[kcrudup]

FWIW, I had to set

split_lock_detect=off

otherwise both Chrome and VMWare would OOPS.

[onlyLinuxLuvUBack]

BTW, for those who are still in the dark. "operations with lock prefix which go across a cache line boundary" is referring to a CPU instruction that performs some sort of read-modify-write operation that cannot be interrupted, such as atomically adding 1 to the value at a certain memory address. These form the basis of thread synchronization, in multiprocessor systems, and their efficiency increasingly affects system performance, as CPU core counts scale ever higher.

A split-lock happens when the data being operated on, by one of these instructions, isn't entirely contained within a single cacheline. When that happens, the CPU core executing the instruction has to do additional work to get & hold exclusive ownership of both cachelines. The suggestion of a "bus lock" implies that it blocks memory bus operations on other cores, as well, which could be seriously detrimental to overall system performance.

In newer CPU ISAs (e.g. AArch64, RISC V), they could take the view that this is illegal and avoid having to handle it by just forcing your program to crash. However, because some older x86 CPUs allowed it, newer ones would break coveted backwards-compatibility if they didn't support it.

Sorry if I oversimplified anything. I hope that helps someone.

All hail x86 !

[coder]

FWIW, I had to set

split_lock_detect=off

otherwise both Chrome and VMWare would OOPS.

It could be due to a 3rd party library, in one or both cases.

Honestly, I expect modern compilers are probably good at warning about unaligned atomics. So, that further suggests it's not 1st party code in Chrome.

[coder]

All hail x86 !

Meh, it is what it is.

I doubt most of us using it are doing so for more than pragmatic reasons. I won't mind leaving it behind, when it's practical for me to do so.