在 2022/6/27 12:27, Alex Shi 写道:
On Mon, Jun 27, 2022 at 11:10 AM YanTeng Si <siyanteng@xxxxxxxxxxx> wrote:
在 2022/6/26 20:22, yizhou.tang@xxxxxxxxxx 写道:
From: Tang Yizhou <yizhou.tang@xxxxxxxxxx>
Translate locking/mutex-design.rst into Chinese.
Signed-off-by: Tang Yizhou <yizhou.tang@xxxxxxxxxx>
---
.../translations/zh_CN/locking/index.rst | 2 +-
.../zh_CN/locking/mutex-design.rst | 144 ++++++++++++++++++
2 files changed, 145 insertions(+), 1 deletion(-)
create mode 100644 Documentation/translations/zh_CN/locking/mutex-design.rst
diff --git a/Documentation/translations/zh_CN/locking/index.rst b/Documentation/translations/zh_CN/locking/index.rst
index 76a8be9bf78b..f0b10707668d 100644
--- a/Documentation/translations/zh_CN/locking/index.rst
+++ b/Documentation/translations/zh_CN/locking/index.rst
@@ -14,6 +14,7 @@
.. toctree::
:maxdepth: 1
+ mutex-design
spinlocks
TODOList:
@@ -22,7 +23,6 @@ TODOList:
* lockdep-design
* lockstat
* locktorture
- * mutex-design
* rt-mutex-design
* rt-mutex
* seqlock
diff --git a/Documentation/translations/zh_CN/locking/mutex-design.rst b/Documentation/translations/zh_CN/locking/mutex-design.rst
new file mode 100644
index 000000000000..fd31017bf8ce
--- /dev/null
+++ b/Documentation/translations/zh_CN/locking/mutex-design.rst
@@ -0,0 +1,144 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/locking/mutex-design.rst
+
+:翻译:
+
+ 唐艺舟 Tang Yizhou <tangyeechou@xxxxxxxxx>
+
+================
+通用互斥锁子系统
+================
+
+:初稿:
+
+ Ingo Molnar <mingo@xxxxxxxxxx>
+
+:更新:
+
+ Davidlohr Bueso <davidlohr@xxxxxx>
+
+什么是互斥锁？
+--------------
+
+在Linux内核中，互斥锁（mutex）指的是一个特殊的加锁原语，它在共享内存系统上
+强制保证序列化，而不仅仅是指在学术界或类似的理论教科书中出现的通用术语“相互
+排斥”。互斥锁是一种睡眠锁，它的行为类似于二进制信号量（semaphores），在
+2006年被引入时[1]，作为后者的替代品。这种新的数据结构提供了许多优点，包括更
+简单的接口，以及在当时更少的代码量（见劣势）。
+
+[1] https://lwn.net/Articles/164802/
+
+实现
+----
+
+互斥锁由“struct mutex”表示，在include/linux/mutex.h中定义，并在
+kernel/locking/mutex.c中实现。这些锁使用一个原子变量（->owner）来跟踪
+它们生命周期内的锁状态。字段owner实际上包含的是指向当前锁所有者的
+`struct task_struct *` 指针，因此如果无人持有锁，则它的值为空（NULL）。
+由于task_struct的指针至少按L1_CACHE_BYTES对齐，低位（3）被用来存储额外
+的状态（例如，等待者列表非空）。在其最基本的形式中，它还包括一个等待队列和
+一个确保对其序列化访问的自旋锁。此外，CONFIG_MUTEX_SPIN_ON_OWNER=y的
+系统使用一个自旋MCS锁（->osq，译注：MCS是两个人名的合并缩写），在下文的
+（ii）中描述。
+
+准备获得一把自旋锁时，有三种可能经过的路径，取决于锁的状态：
+
+(i) 快速路径：试图通过调用cmpxchg()修改锁的所有者为当前任务，以此原子化地
+ 获取锁。这只在无竞争的情况下有效（cmpxchg()检查值是否为0，所以3个状态
+ 比特必须为0）。如果锁处在竞争状态，代码进入下一个可能的路径。
+
+(ii) 中速路径：也就是乐观自旋，当锁的所有者正在运行并且没有其它优先级更高的
+ 任务（need_resched，需要重新调度）准备运行时，当前任务试图自旋来获得
+ 锁。原理是，如果锁的所有者正在运行，它很可能不久就会释放锁。互斥锁自旋体
+ 使用MCS锁排队，这样只有一个自旋体可以竞争互斥锁。
+
+ MCS锁（由Mellor-Crummey和Scott提出）是一个简单的自旋锁，它具有一些
+ 理想的特性，比如公平，以及每个CPU在试图获得锁时在一个本地变量上自旋。
+ 它避免了常见的“检测-设置”自旋锁实现导致的昂贵的缓存线跳跃（cacheline
how about :
导致的缓存行跳跃（cacheline bouncing）这种昂贵的开销？
Both look fine. and may we don't have a better way to reflect the fact
cache bouncing between cpus?
how about cpu核间缓存行弹跳?
Thanks，
Yanteng
Anyway,
Reviewed-by: Alex Shi <alexs@xxxxxxxxxx>
