=================
LINUX内核内存屏障
=================

By: David Howells <dhowells@redhat.com>
Paul E. McKenney <paulmck@linux.vnet.ibm.com>
译: kouu <kouucocu@126.com>

出处: Linux内核文档 -- Documentation/memory-barriers.txt

目录:

(*) 内存访问抽象模型.

- 操作设备.
- 保证.

(*) 什么是内存屏障?

- 各式各样的内存屏障.
- 关于内存屏障, 不能假定什么?
- 数据依赖屏障.
- 控制依赖.
- SMP内存屏障的配对使用.
- 内存屏障举例.
- 读内存屏障与内存预取.

(*) 内核中显式的内存屏障.

- 编译优化屏障.
- CPU内存屏障.
- MMIO写屏障.

(*) 内核中隐式的内存屏障.

- 锁相关函数.
- 禁止中断函数.
- 睡眠唤醒函数.
- 其他函数.

(*) 跨CPU的锁的屏障作用.

- 锁与内存访问.
- 锁与IO访问.

(*) 什么地方需要内存屏障?

- 处理器间交互.
- 原子操作.
- 访问设备.
- 中断.

(*) 内核中I/O屏障的作用.

(*) 最小限度有序的假想模型.

(*) CPU cache的影响.

- Cache一致性.
- Cache一致性与DMA.
- Cache一致性与MMIO.

(*) CPU所能做到的.

- 特别值得一提的Alpha处理器.

(*) 使用示例.

- 环型缓冲区.

(*) 引用.

================
内存访问抽象模型
================

考虑如下抽象系统模型:

: :
: :
: :
+-------+ : +--------+ : +-------+
| | : | | : | |
| | : | | : | |
| CPU 1 |<----->| 内存 |<----->| CPU 2 |
| | : | | : | |
| | : | | : | |
+-------+ : +--------+ : +-------+
^ : ^ : ^
| : | : |
| : | : |
| : v : |
| : +--------+ : |
| : | | : |
| : | | : |
+---------->| 设备 |<----------+
: | | :
: | | :
: +--------+ :
: :

假设每个CPU都分别运行着一个会触发内存访问操作的程序. 对于这样一个CPU, 其内存访问
顺序是非常松散的, 在保证程序上下文逻辑关系的前提下, CPU可以按它所喜欢的顺序来执
行内存操作. 类似的, 编译器也可以将它输出的指令安排成任何它喜欢的顺序, 只要保证不
影响程序表面的执行逻辑.

(译注:

内存屏障是为应付内存访问操作的乱序执行而生的. 那么, 内存访问为什么会乱序呢? 这里
先简要介绍一下:

现在的CPU一般采用流水线来执行指令. 一个指令的执行被分成: 取指, 译码, 访存, 执行,
写回, 等若干个阶段.

指令流水线并不是串行化的, 并不会因为一个耗时很长的指令在"执行"阶段呆很长时间, 而
导致后续的指令都卡在"执行"之前的阶段上.

相反, 流水线中的多个指令是可以同时处于一个阶段的, 只要CPU内部相应的处理部件未被
占满. 比如说CPU有一个加法器和一个除法器, 那么一条加法指令和一条除法指令就可能同
时处于"执行"阶段, 而两条加法指令在"执行"阶段就只能串行工作.

这样一来, 乱序可能就产生了. 比如一条加法指令出现在一条除法指令的后面, 但是由于除
法的执行时间很长, 在它执行完之前, 加法可能先执行完了. 再比如两条访存指令, 可能由
于第二条指令命中了cache(或其他原因)而导致它先于第一条指令完成.

一般情况下, 指令乱序并不是CPU在执行指令之前刻意去调整顺序. CPU总是顺序的去内存里
面取指令, 然后将其顺序的放入指令流水线. 但是指令执行时的各种条件, 指令与指令之间
的相互影响, 可能导致顺序放入流水线的指令, 最终乱序执行完成. 这就是所谓的"顺序流
入, 乱序流出".

指令流水线除了在资源不足的情况下会卡住之外(如前所述的一个加法器应付两条加法指令)
, 指令之间的相关性才是导致流水线阻塞的主要原因.

下文中也会多次提到, CPU的乱序执行并不是任意的乱序, 而必须保证上下文依赖逻辑的正
确性. 比如: a++; b=f(a); 由于b=f(a)这条指令依赖于第一条指令(a++)的执行结果, 所以
b=f(a)将在"执行"阶段之前被阻塞, 直到a++的执行结果被生成出来.

如果两条像这样有依赖关系的指令挨得很近, 后一条指令必定会因为等待前一条执行的结果
, 而在流水线中阻塞很久. 而编译器的乱序, 作为编译优化的一种手段, 则试图通过指令重
排将这样的两条指令拉开距离, 以至于后一条指令执行的时候前一条指令结果已经得到了,
那么也就不再需要阻塞等待了.

相比于CPU的乱序, 编译器的乱序才是真正对指令顺序做了调整. 但是编译器的乱序也必须
保证程序上下文的依赖逻辑.

由于指令执行存在这样的乱序, 那么自然, 由指令执行而引发的内存访问势必也可能乱序.
)

在上面的图示中, 一个CPU执行内存操作所产生的影响, 一直要到该操作穿越该CPU与系统中
其他部分的界面(见图中的虚线)之后, 才能被其他部分所感知.

举例来说, 考虑如下的操作序列:

CPU 1 CPU 2
=============== ===============
{ A == 1; B == 2 }
A = 3; x = A;
B = 4; y = B;

这一组访问指令在内存系统(见上图的中间部分)上生效的顺序, 可以有24种不同的组合:

STORE A=3, STORE B=4, x=LOAD A->3, y=LOAD B->4
STORE A=3, STORE B=4, y=LOAD B->4, x=LOAD A->3
STORE A=3, x=LOAD A->3, STORE B=4, y=LOAD B->4
STORE A=3, x=LOAD A->3, y=LOAD B->2, STORE B=4
STORE A=3, y=LOAD B->2, STORE B=4, x=LOAD A->3
STORE A=3, y=LOAD B->2, x=LOAD A->3, STORE B=4
STORE B=4, STORE A=3, x=LOAD A->3, y=LOAD B->4
STORE B=4, ...
...

然后这就产生四种不同组合的结果值:

x == 1, y == 2
x == 1, y == 4
x == 3, y == 2
x == 3, y == 4

甚至于, 一个CPU在内存系统上提交的STORE操作还可能不会以相同的顺序被其他CPU所执行
的LOAD操作所感知.

进一步举例说明, 考虑如下的操作序列:

CPU 1 CPU 2
=============== ===============
{ A == 1, B == 2, C = 3, P == &A, Q == &C }
B = 4; Q = P;
P = &B D = *Q;

这里有一处明显的数据依赖, 因为在CPU2上, LOAD到D里面的值依赖于从P获取到的地址. 在
操作序列的最后, 下面的几种结果都是有可能出现的:

(Q == &A) 且 (D == 1)
(Q == &B) 且 (D == 2)
(Q == &B) 且 (D == 4)

注意, CPU2决不会将C的值LOAD到D, 因为CPU保证在将P的值装载到Q之后才会执行对*Q的
LOAD操作(译注: 因为存在数据依赖).

操作设备
--------

对于一些设备, 其控制寄存器被映射到一组内存地址集合上, 而这些控制寄存器被访问的顺
序是至关重要的. 假设, 一个以太网卡拥有一些内部寄存器, 通过一个地址端口寄存器(A)
和一个数据端口寄存器(D)来访问它们. 要读取编号为5的内部寄存器, 可能使用如下代码:
*A = 5;
x = *D;

但是这可能会表现为以下两个序列之一(译注: 因为从程序表面看, A和D是不存在依赖的):

STORE *A = 5, x = LOAD *D
x = LOAD *D, STORE *A = 5

其中的第二种几乎肯定会导致错误, 因为它在读取寄存器之后才设置寄存器的编号.

保证
----

对于一个CPU, 它最低限度会提供如下的保证:

(*) 对于一个CPU, 在它上面出现的有上下文依赖关系的内存访问将被按顺序执行. 这意味
着:

Q = P; D = *Q;

CPU会顺序执行以下访存:

Q = LOAD P, D = LOAD *Q

并且总是按这样的顺序.

(*) 对于一个CPU, 重叠的LOAD和STORE操作将被按顺序执行. 这意味着:

a = *X; *X = b;

CPU只会按以下顺序执行访存:

a = LOAD *X, STORE *X = b

同样, 对于:

*X = c; d = *X;

CPU只会按以下顺序执行访存:

STORE *X = c, d = LOAD *X

(如果LOAD和STORE的目标指向同一块内存地址, 则认为是重叠).

还有一些事情是必须被假定或者必须不被假定的:

(*) 必须不能假定无关的LOAD和STORE会按给定的顺序被执行. 这意味着:

X = *A; Y = *B; *D = Z;

可能会得到如下几种执行序列之一:

X = LOAD *A, Y = LOAD *B, STORE *D = Z
X = LOAD *A, STORE *D = Z, Y = LOAD *B
Y = LOAD *B, X = LOAD *A, STORE *D = Z
Y = LOAD *B, STORE *D = Z, X = LOAD *A
STORE *D = Z, X = LOAD *A, Y = LOAD *B
STORE *D = Z, Y = LOAD *B, X = LOAD *A

(*) 必须假定重叠内存访问可能被合并或丢弃. 这意味着:

X = *A; Y = *(A + 4);

可能会得到如下几种执行序列之一:

X = LOAD *A; Y = LOAD *(A + 4);
Y = LOAD *(A + 4); X = LOAD *A;
{X, Y} = LOAD {*A, *(A + 4) };

同样, 对于:

*A = X; Y = *A;

可能会得到如下几种执行序列之一:

STORE *A = X; Y = LOAD *A;
STORE *A = Y = X;