内存屏障原语

来自于在CU的一个讨论：
http://linux.chinaunix.net/bbs/thread-713279-1-1.html
讨论完了给一个总结，有些话是别人说的，有的还是clf的网友的，为了不使文档显得杂乱，都不具名了。
欢迎批评指正！


内核中定义的内存屏障原语有：

#define barrier() __asm__ __volatile__("": : :"memory")
#define mb() alternative("lock; addl $0,0(%%esp)", "mfence", X86_FEATURE_XMM2)
#define rmb() alternative("lock; addl $0,0(%%esp)", "lfence", X86_FEATURE_XMM2)

#ifdef CONFIG_SMP
#define smp_mb() mb()
#define smp_rmb() rmb()
#define smp_wmb() wmb()
#define smp_read_barrier_depends() read_barrier_depends()
#define set_mb(var, value) do { (void) xchg(&var, value); } while (0)
#else
#define smp_mb() barrier()
#define smp_rmb() barrier()
#define smp_wmb() barrier()
#define smp_read_barrier_depends() do { } while(0)
#define set_mb(var, value) do { var = value; barrier(); } while (0)
#endif


1). smp_xxx()和xxx()的区别

为了给其它CPU也提供相关的barrier宏。 例如x86的rmb()是用了lfence指令，但其它CPU不能用这个指令。


2). 关于barrier()宏，jkl大师是这么说的：

CPU越过内存屏障后，将刷新自己对存储器的缓冲状态。这条语句实际上不生成任何代码，但可使gcc在
barrier()之后刷新寄存器对变量的分配。

也就是说，barrier()宏只约束gcc编译器，不约束运行时的CPU行为。 举例：

1 int a = 5, b = 6;
2 barrier();
3 a = b;

在line 3，GCC不会用存放b的寄存器给a赋值，而是invalidate b的Cache line，重新读内存中的b值，赋值给a。


3). mb() vs. rmb() vs. wmb()

rmb()不允许读操作穿过内存屏障；wmb()不允许写操作穿过屏障；而mb()二者都不允许。

看IA32上wmb()的定义：
#ifdef CONFIG_X86_OOSTORE
#define wmb() alternative("lock;addl $0,0(%%esp)", "sfence", X86_FEATURE_XMM);
#else
#define wmb() __asm__ __volatile__ ("": : :"memory");
#endif

Intel和AMD都没有在IA32 CPU中实现乱序写(Out-Of-Order Store)，所以wmb()定义为空操作，不约束CPU行为；但
有些IA32 CPU厂商实现了OOO Store，所以就有了使用sfence的那个wmb()实现。


4). 内存屏障的体系结构语义

4.1) 只有一个主体(CPU或DMA控制器)访问内存时，无论如何也不需要barrier；但如果有两个或更多主体访问内存，且
其中有一个在观测另一个，就需要barrier了。

4.2) IA32 CPU调用有lock前缀的指令，或者如xchg这样的指令，会导致其它的CPU也触发一定的动作来同步自己的Cache。
CPU的#lock引脚链接到北桥芯片(North Bridge)的#lock引脚，当带lock前缀的执行执行时，北桥芯片会拉起#lock
电平，从而锁住总线，直到该指令执行完毕再放开。 而总线加锁会自动invalidate所有CPU对 _该指令涉及的内存_
的Cache，因此barrier就能保证所有CPU的Cache一致性。

4.3) 接着解释。
lock前缀(或cpuid、xchg等指令)使得本CPU的Cache写入了内存，该写入动作也会引起别的CPU invalidate其Cache。
IA32在每个CPU内部实现了Snoopying(BUS-Watching)技术，监视着总线上是否发生了写内存操作(由某个CPU或DMA控
制器发出的)，只要发生了，就invalidate相关的Cache line。 因此，只要lock前缀导致本CPU写内存，就必将导致
所有CPU去invalidate其相关的Cache line。

两个地方可能除外：
-> 如果采用write-through策略，则根本不存在缓存一致性问题(Linux对全部内存采用write-back策略);
-> TLB也是Cache，但它的一致性(至少在IA32上)不能通过Snoopying技术解决，而是要发送
INVALIDATE_TLB_VECTOR这个IPI给其它的CPU。

4.4) 进一步解释，MESI协议

包括IA32的许多体系结构的CPU，为了保证缓存一致性，实现了MESI协议。

M: Modified，已修改
E: Exclusive，排他
S: Shared，共享
I: Invalid，无效

IA32 的CPU实现了MESI协议来保证Cache coherence。 CPU的总线监测单元，始终监视着总线上所有的内存写操作，
以便随时调整自己的Cache状态。

-> Modified。 本CPU写，则直接写到Cache，不产生总线事物；其它CPU写，则不涉及本CPU的Cache，其它CPU
读，则本CPU需要把Cache line中的数据提供给它，而不是让它去读内存。

-> Exclusive。只有本CPU有该内存的Cache，而且和内存一致。 本CPU的写操作会导致转到Modified状态。

-> Shared。 多个CPU都对该内存有Cache，而且内容一致。任何一个CPU写自己的这个Cache都必须通知其它
的CPU。

-> Invalid。 一旦Cache line进入这个状态，CPU读数据就必须发出总线事物，从内存读。


5) 考虑到DMA

5.1). Wirte through策略。 这种情形比较简单。

-> 本CPU写内存，是write through的，因此无论什么时候DMA读内存，读到的都是正确数据。
-> DMA写内存，如果DMA要写的内存被本CPU缓存了，那么必须Invalidate这个Cache line。下次CPU读它，就
直接从内存读。

5.2). Write back策略。 这种情形相当复杂。

-> DMA读内存。被本CPU总线监视单元发现，而且本地Cache中有Modified数据，本CPU就截获DMA的内存读操作，
把自己Cache Line中的数据返回给它。

-> DMA写内存。而且所写的位置在本CPU的Cache中，这又分两种情况：
a@ Cache Line状态未被CPU修改过(即cache和内存一致)，那么invalidate该cache line。
b@ Cache Line状态已经被修改过，又分2种情况：

<1> DMA写操作会替换CPU Cache line所对应的整行内存数据，那么DMA写，CPU则invalidate
自己的Cache Line。
<2> DMA写操作只替换Cache Line对应的内存数据的一部分，那么CPU必须捕获DMA写操作的新
数据(即DMA想把它写入内存的)，用来更新Cache Line的相关部分。

 

----
天吖度绱耍疫M杯中物!
[Original] [Print] [Top] 
Subject: [精华] Re: 尝试总结memory barrier
Author: zyzii    Posted: 2007-07-25 12:12    Length: 25 byte(s) 
[Original] [Print] [Top] 
毛哥书的下册SMP有介绍啊。 
----
kscope 很好用的。和source insight 差不多了 。
[Original] [Print] [Top] 
Subject: [精华] Re: 尝试总结memory barrier
Author: leviathan    Posted: 2007-07-25 18:21    Length: 31 byte(s) 
[Original] [Print] [Top] 
《情景分析》讲barrier部分太少了 
----
天吖度绱耍疫M杯中物!
[Original] [Print] [Top] 
Subject: [精华] Re: 尝试总结memory barrier
Author: zyzii    Posted: 2007-07-25 19:06    Length: 47 byte(s) 
[Original] [Print] [Top] 
呵呵，这个东西，讨论来讨论去就会到BNN的地盘了。 
----
kscope 很好用的。和source insight 差不多了 。
[Original] [Print] [Top] 
Subject: [精华] Re: 尝试总结memory barrier
Author: wheelz    Posted: 2007-07-25 19:19    Length: 50 byte(s) 
[Original] [Print] [Top] 
内核Documentation下有一篇非常好的文档.可以作为补充 
----
http://www.kernelchina.org/
[Original] [Print] [Top] 
Subject: Re: 尝试总结memory barrier
Author: sky3452    Posted: 2007-07-26 10:21    Length: 14 byte(s) 
[Original] [Print] [Top] 
好文，受益匪浅 
[Original] [Print] [Top] 
Subject: Re: 尝试总结memory barrier
Author: leviathan    Posted: 2007-07-26 12:31    Length: 166 byte(s) 
[Original] [Print] [Top] 

才看到，谢谢:) 这个文档估计就是去年他们的讨论结果，居然有2k多行

主楼不能排版，一排版就出乱码，在这层上传个txt试试:)


----
天吖度绱耍疫M杯中物!
--
Attached file: 653878-%B3%A2%CA%D4%D7%DC%BD%E1memory%20barrier.txt.gz
[Original] [Print] [Top] 
Subject: Re: 尝试总结memory barrier
Author: zyzii    Posted: 2007-10-12 12:03    Length: 335 byte(s) 
[Original] [Print] [Top] 

“在line 3，GCC不会用存放b的寄存器给a赋值，而是invalidate b的Cache line，重新读内存中的b值，赋值给a。”

感觉这个是不对的。上面都说了“barrier()宏只约束gcc编译器，不约束运行时的CPU行为”，
而invalidate Cache line要调用wbinvd命令，我对GCC的代码进行grep 没有发现使用wbinvd的地方。


----
应用程序是LINUX的软肋。
[Original] [Print] [Top] 
Subject: Re: 尝试总结memory barrier
Author: zyzii    Posted: 2007-10-12 13:18    Length: 1,661 byte(s) 
[Original] [Print] [Top] 
“
4.2) IA32
CPU调用有lock前缀的指令，或者如xchg这样的指令，会导致其它的CPU也触发一定的动作来同步自
己的Cache。
CPU的#lock引脚链接到北桥芯片(North
Bridge)的#lock引脚，当带lock前缀的执行执行时，北桥芯片会拉起#lock
电平，从而锁住总线，直到该指令执行完毕再放开。 而总线加锁会自动invalidate所有CPU对
_该指令涉及的内存_
的Cache，因此barrier就能保证所有CPU的Cache一致性。 ”


 
   总线加锁的功能是保证程序执行的顺序不乱掉，
一旦加LOCK指令了，CPU会将此指令前的读写操作都串行完成，这最主要的作用是使CPU的预取等无
效了。
在这个串行操作中，MESI协议会起作用。
但保证所有CPU的Cache一致性的是MESI协议，这是硬件上保证的。
barrier是对GCC编译器做约束，是软件层次上的。
“因此barrier就能保证所有CPU的Cache一致性”这种说法是不对的。
 

“4.3) 接着解释。
lock前缀(或cpuid、xchg等指令)使得本CPU的Cache写入了内存，该写入动作也会引起别的CPU
invalidate其Cache。
IA32在每个CPU内部实现了Snoopying(BUS-Watching)技术，监视着总线上是否发生了写内存操作(?
赡掣鯟PU或DMA控
制器发出的)，只要发生了，就invalidate相关的Cache line。
因此，只要lock前缀导致本CPU写内存，就必将导致
所有CPU去invalidate其相关的Cache line。 ”


 
lock指令保证程序执行的顺序不乱掉，没有将“本CPU的Cache写入了内存”的功能。
总线监视功能是由各个CPU的CACHE完成的，
这个功能可以算是MESI协议的实现。MESI保证了SMP下的CACHE一致性。
   
----
应用程序是LINUX的软肋。
[Original] [Print] [Top] 
Subject: Re: 尝试总结memory barrier
Author: zyzii    Posted: 2007-10-12 13:34    Length: 632 byte(s) 
[Original] [Print] [Top] 
  
memory barrier的实质是对内存的操作施加顺序上的约束。
Memory barrier, also known as membar or memory fence, is a class of instructions which
cause a central processing unit (CPU) to enforce an ordering constraint on memory
operations issued before and after the barrier instruction.

  上文源于：http://www.answers.com/topic/memory-barrier

  至于“SMP情况下CACHE的一致性”只是memory
barrier在执行lock,sfence,lfence等指令时的副作用 !!!!，
    “SMP情况下CACHE的一致性”是由MESI来做的。
  
----
应用程序是LINUX的软肋。
[Original] [Print] [Top] 
Subject: Re: 尝试总结memory barrier
Author: leviathan    Posted: 2007-10-12 14:29    Length: 257 byte(s) 
[Original] [Print] [Top] 
这里的说法的确有问题，应该修正为：

“在line 3，GCC不会用存放b的寄存器给a赋值，而是读内存中的b值，赋值给a。”

至于读内存中的b是否会引发cache invalidate，那就是CPU的事了。

谢谢指正。


----
天吖度绱耍疫M杯中物!
[Original] [Print] [Top] 
Subject: Re: 尝试总结memory barrier
Author: zyzii    Posted: 2007-10-13 17:13    Length: 230 byte(s) 
[Original] [Print] [Top] 
"一旦加LOCK指令了，CPU会将此指令前的读写操作都串行完成，这最主要的作用是使CPU的预取等无效了。"

仔细看了一下INTEL的手册，LOCK不能使CPU的预取无效，所以这句是不对的。CPUID这种串行语句才会使CPU的预取无效。 
----
应用程序是LINUX的软肋。
[Original] [Print] [Top] 
Subject: Re: 尝试总结memory barrier
Author: crspo    Posted: 2007-10-20 12:27    Length: 427 byte(s) 
[Original] [Print] [Top] 
这个问题与体系结构密切相关

首先要明白cache coherence能解决什么问题?
coherence与consistency的区别?

在IA-32上 rmb()/wmb()/mb() 与在多处理器下IA-32遵循的Processor Consistency密切相关,
大家不但可以参考IA-32的手册，有兴趣的话可以参考一下AMD64的手册,那里的解释更完善.

另外wmb()/MFENCE的语义与体系结构中的write buffer/write-combining buffer功能和作用密切相关.  
[Original] [Print] [Top] 
Subject: Re: 尝试总结memory barrier
Author: asand    Posted: 2007-10-22 16:23    Length: 3,194 byte(s) 
[Original] [Print] [Top] 
4.1) 只有一个主体(CPU或DMA控制器)访问内存时，无论如何也不需要barrier；但如果有两个或更多主体访问内存，且
其中有一个在观测另一个，就需要barrier了

这个好像不大对吧?下面的文字来自<<LDD3>>

I/O 寄存器和常规内存
不管硬件寄存器和内存之间的强相似性, 存取 I/O 寄存器的程序员必须小心避免被 CPU(或者编译器)优化所戏弄, 它可能修改希望的 I/O 行为.

I/O 寄存器和 RAM 的主要不同是 I/O 操作有边际效果, 而内存操作没有: 一个内存写的唯一效果是存储一个值到一个位置, 并且一个内存读返回最近写到那里的值. 因为内存存取速度对 CPU 性能是至关重要的, 这种无边际效果的情况已被多种方式优化: 值被缓存, 并且 读/写指令被重编排.

编译器能够缓存数据值到 CPU 寄存器而不写到内存, 并且即便它存储它们, 读和写操作都能够在缓冲内存中进行而不接触物理 RAM. 重编排也可能在编译器级别和在硬件级别都发生: 常常一个指令序列能够执行得更快, 如果它以不同于在程序文本中出现的顺序来执行, 例如, 为避免在 RISC 流水线中的互锁. 在CISC 处理器, 要花费相当数量时间的操作能够和其他的并发执行, 更快的.

当应用于传统内存时(至少在单处理器系统)这些优化是透明和有益的, 但是它们可能对正确的 I/O 操作是致命的, 因为它们干扰了那些"边际效果", 这是主要的原因为什么一个驱动存取 I/O 寄存器. 处理器无法预见这种情形, 一些其他的操作(在一个独立处理器上运行, 或者发生在一个 I/O 控制器的事情)依赖内存存取的顺序. 编译器或者 CPU 可能只尽力胜过你并且重编排你请求的操作; 结果可能是奇怪的错误而非常难于调试. 因此, 一个驱动必须确保没有进行缓冲并且在存取寄存器时没有发生读或写的重编排.

硬件缓冲的问题是最易面对的:底层的硬件已经配置(或者自动地或者通过 Linux 初始化代码)成禁止任何硬件缓冲, 当存取 I/O 区时(不管它们是内存还是端口区域).

对编译器优化和硬件重编排的解决方法是安放一个内存屏障在必须以一个特殊顺序对硬件(或者另一个处理器)可见的操作之间. Linux 提供 4 个宏来应对可能的排序需要:

#include <linux/kernel.h>
void barrier(void)
这个函数告知编译器插入一个内存屏障但是对硬件没有影响. 编译的代码将所有的当前改变的并且驻留在 CPU 寄存器的值存储到内存, 并且后来重新读取它们当需要时. 对屏障的调用阻止编译器跨越屏障的优化, 而留给硬件自由做它的重编排.

#include <asm/system.h>
void rmb(void);
void read_barrier_depends(void);
void wmb(void);
void mb(void);
这些函数插入硬件内存屏障在编译的指令流中; 它们的实际实例是平台相关的. 一个 rmb ( read memory barrier) 保证任何出现于屏障前的读在执行任何后续读之前完成. wmb 保证写操作中的顺序, 并且 mb 指令都保证. 每个这些指令是一个屏障的超集.

read_barrier_depends 是读屏障的一个特殊的, 弱些的形式. 而 rmb 阻止所有跨越屏障的读的重编排, read_barrier_depends 只阻止依赖来自其他读的数据的读的重编排. 区别是微小的, 并且它不在所有体系中存在. 除非你确切地理解做什么, 并且你有理由相信, 一个完整的读屏障确实是一个过度地性能开销, 你可能应当坚持使用 rmb.

void smp_rmb(void);
void smp_read_barrier_depends(void);
void smp_wmb(void);
void smp_mb(void);
屏障的这些版本仅当内核为 SMP 系统编译时插入硬件屏障; 否则, 它们都扩展为一个简单的屏障调用.

 

[Original] [Print] [Top] 

« Previous thread
应用层要支持connect函数的正确连接，2.6内核make menuconfig需哪些选项支持？