Linux 5.19 will “make life miserable” by slowing down misbehaving Split-Lock apps

0

In 2020, Intel engineers working on the Linux kernel added split lock detection to provide warning when an atomic operation spans multiple cache lines and requires a global bus lock for atomicity. A warning is no longer deemed useful enough, so the intent moving forward is to “make life miserable” for such misbehaving userspace applications by slowing performance in the hope that application developers manage their code better.

Although the default behavior is to provide a warning to userspace applications that abuse shared locks, previous patches allow applications to be killed. Split locks can take at least 1000 cycles longer than an atomic operation in a single cache line. Shared locks cause other processors and other bus agents to be locked out of control, which affects overall system performance.

This Linux shared lock detection relied on modern x86_64 processor features to be able to throw an alignment check exception when hitting a shared lock. Existing kernel behavior can be tuned using the “split_lock_detect=” kernel parameter.

Intel engineer Tony Luck offered to make things more aggressive and “make life miserable for shared lockers” with patches released earlier this year. The patches currently queued for Linux 5.19 attempt to slow down the offending application so much that the developer(s) will hopefully fix the problem. The new “sequential” mode forces sequential access for userspace shared locks. In turn, this mode also ensures that the overall system performance is better under these conditions.

Hence a new option to “slow it down in a way that makes it boring”.

The main reason for this change is to provide better quality of service to the rest of the applications running on the system. Internal tests show that even with many processes dividing locks, the performance of the rest of the system is much more responsive.

Add a new choice to the existing “sequential” “split_lock_detect” startup parameter. In this mode, shared lock detection is enabled. When an application attempts to perform a bus lockout, the #AC.

1) Blocks (in an interrupted fashion) until it can get the semaphore
If interrupted, just come back. Suppose the signal kills the task or drives away the execution of the instruction that is trying to get the bus locked.
2) Disable split lock detection for the current kernel
3) Schedule a work queue to re-enable split lock detection in 2 jiffies
4) Returns

This “make life miserable” change was submitted as x86 shared lockdown updates for Linux 5.19.

Share.

Comments are closed.