요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
===============================
Bus lock detection and handling
===============================
:Copyright: |copy| 2021 Intel Corporation
:Authors: - Fenghua Yu <[email protected]>
- Tony Luck <[email protected]>
Problem
=======
A split lock is any atomic operation whose operand crosses two cache lines.
Since the operand spans two cache lines and the operation must be atomic,
the system locks the bus while the CPU accesses the two cache lines.
A bus lock is acquired through either split locked access to writeback (WB)
memory or any locked access to non-WB memory. This is typically thousands of
cycles slower than an atomic operation within a cache line. It also disrupts
performance on other cores and brings the whole system to its knees.
Detection
=========
Intel processors may support either or both of the following hardware
mechanisms to detect split locks and bus locks. Some AMD processors also
support bus lock detect.
#AC exception for split lock detection
--------------------------------------
Beginning with the Tremont Atom CPU split lock operations may raise an
Alignment Check (#AC) exception when a split lock operation is attempted.
#DB exception for bus lock detection
------------------------------------
Some CPUs have the ability to notify the kernel by an #DB trap after a user
instruction acquires a bus lock and is executed. This allows the kernel to
terminate the application or to enforce throttling.
Software handling
=================
The kernel #AC and #DB handlers handle bus lock based on the kernel
parameter "split_lock_detect". Here is a summary of different options:
+------------------+----------------------------+-----------------------+
|split_lock_detect=|#AC for split lock |#DB for bus lock |
+------------------+----------------------------+-----------------------+
|off |Do nothing |Do nothing |
+------------------+----------------------------+-----------------------+
|warn |Kernel OOPs |Warn once per task and |
|(default) |Warn once per task, add a |and continues to run. |
| |delay, add synchronization | |
| |to prevent more than one | |
| |core from executing a | |
| |split lock in parallel. | |
| |sysctl split_lock_mitigate | |
| |can be used to avoid the | |
| |delay and synchronization | |
| |When both features are | |
| |supported, warn in #AC | |
+------------------+----------------------------+-----------------------+
|fatal |Kernel OOPs |Send SIGBUS to user. |
| |Send SIGBUS to user | |
| |When both features are | |
| |supported, fatal in #AC | |
+------------------+----------------------------+-----------------------+
|ratelimit:N |Do nothing |Limit bus lock rate to |
|(0 < N <= 1000) | |N bus locks per second |
| | |system wide and warn on|
| | |bus locks. |
+------------------+----------------------------+-----------------------+
Usages
======
Detecting and handling bus lock may find usages in various areas:
It is critical for real time system designers who build consolidated real
time systems. These systems run hard real time code on some cores and run
"untrusted" user processes on other cores. The hard real time cannot afford
to have any bus lock from the untrusted processes to hurt real time
performance. To date the designers have been unable to deploy these
solutions as they have no way to prevent the "untrusted" user code from
generating split lock and bus lock to block the hard real time code to
access memory during bus locking.
It's also useful for general computing to prevent guests or user
applications from slowing down the overall system by executing instructions
with bus lock.
Guidance
========
off
---
Disable checking for split lock and bus lock. This option can be useful if
there are legacy applications that trigger these events at a low rate so
that mitigation is not needed.
warn
----
A warning is emitted when a bus lock is detected which allows to identify
the offending application. This is the default behavior.
fatal
-----
In this case, the bus lock is not tolerated and the process is killed.
ratelimit
---------
A system wide bus lock rate limit N is specified where 0 < N <= 1000. This
allows a bus lock rate up to N bus locks per second. When the bus lock rate
is exceeded then any task which is caught via the buslock #DB exception is
throttled by enforced sleeps until the rate goes under the limit again.
This is an effective mitigation in cases where a minimal impact can be
tolerated, but an eventual Denial of Service attack has to be prevented. It
allows to identify the offending processes and analyze whether they are
malicious or just badly written.
Selecting a rate limit of 1000 allows the bus to be locked for up to about
seven million cycles each second (assuming 7000 cycles for each bus
lock). On a 2 GHz processor that would be about 0.35% system slowdown.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
문서 범위와 저자
1-12이 `GPL-2.0` 문서는 Linux의 bus-lock detection과 handling을 설명합니다. Copyright는 2021 Intel Corporation이며 저자는 Fenghua Yu `<[email protected]>`와 Tony Luck `<[email protected]>`입니다.
split lock과 bus lock 문제
13-24split lock은 operand가 두 cache line에 걸치는 atomic operation입니다. 두 cache line을 동시에 atomic하게 접근해야 하므로 CPU가 두 line을 access하는 동안 system bus를 lock합니다.
bus lock은 writeback(WB) memory에 대한 split locked access 또는 non-WB memory에 대한 모든 locked access에서 획득됩니다. 한 cache line 안의 atomic operation보다 보통 수천 cycle 느리고 다른 core의 performance까지 방해해 system 전체를 사실상 멈출 수 있습니다.
hardware detection mechanism
25-44Intel processor는 split lock과 bus lock을 감지하는 다음 hardware mechanism 중 하나 또는 둘 다를 지원할 수 있습니다. 일부 AMD processor도 bus-lock detect를 지원합니다.
| exception | 대상 | 동작 |
|---|---|---|
| Alignment Check `#AC` | split lock | Tremont Atom CPU부터 split-lock operation을 시도할 때 `#AC`를 발생시킬 수 있습니다. |
| Debug `#DB` | bus lock | 일부 CPU는 user instruction이 bus lock을 획득해 실행한 뒤 kernel에 `#DB` trap으로 알립니다. kernel은 application을 terminate하거나 throttling할 수 있습니다. |
split_lock_detect 정책 표
45-78kernel의 `#AC`, `#DB` handler는 `split_lock_detect` kernel parameter에 따라 bus lock을 처리합니다.
원문의 ASCII 비교표를 option, split-lock #AC, bus-lock #DB 세 열로 구조화했습니다.
real-time과 general-computing use case
79-97bus lock detection과 handling은 여러 영역에서 유용합니다. 특히 consolidated real-time system은 일부 core에서 hard real-time code를 실행하고 다른 core에서 untrusted user process를 실행합니다. hard real-time code는 untrusted process의 bus lock 때문에 memory access가 막혀서는 안 됩니다.
기존에는 untrusted user code가 split lock이나 bus lock을 만들어 hard real-time performance를 해치는 일을 막을 방법이 없어 이런 solution을 배포하기 어려웠습니다. 일반 computing에서도 guest나 user application이 bus-lock instruction으로 system 전체를 느리게 만드는 것을 방지하는 데 유용합니다.
off, warn, fatal, ratelimit 선택 지침
98-133| mode | 선택 지침 |
|---|---|
| `off` | split lock과 bus lock 검사를 끕니다. event 발생률이 낮아 mitigation이 필요 없는 legacy application이 있을 때 유용합니다. |
| `warn` | bus lock을 감지하면 warning을 내어 offending application을 식별합니다. default behavior입니다. |
| `fatal` | bus lock을 허용하지 않고 process를 kill합니다. |
| `ratelimit:N` | `0 < N <= 1000` 범위의 system-wide 초당 bus-lock limit를 정합니다. 초과하면 `#DB`로 잡힌 task를 강제 sleep시켜 rate가 다시 limit 아래로 내려갈 때까지 throttle합니다. |
`ratelimit`은 최소한의 impact는 허용할 수 있지만 장기적인 Denial of Service attack은 막아야 할 때 효과적입니다. offending process를 식별해 malicious한지 단순히 잘못 작성됐는지도 분석할 수 있습니다.
rate limit 1000을 선택하면 bus lock 하나가 7000 cycle이라고 가정할 때 bus가 매초 약 7 million cycle까지 lock될 수 있습니다. 2 GHz processor에서는 약 0.35% system slowdown입니다.
요약과 해설
buslock.rst:1-133cache line을 가로지르는 atomic access나 non-WB locked access는 system bus를 lock해 다른 core까지 수천 cycle 지연시킬 수 있습니다. Linux는 `split_lock_detect`로 `#AC` split-lock과 `#DB` bus-lock event를 무시, 경고, 종료, system-wide rate limit 중 하나로 처리합니다.
hard real-time workload를 untrusted process와 함께 운용할 때 특히 중요합니다. `warn`은 offending task 식별, `fatal`은 `SIGBUS`, `ratelimit:N`은 초당 N회 이후 강제 sleep을 사용하며 낮은 impact와 DoS 방지를 절충합니다.