什么时候需要cpu_relax()锁

一个最典型的要使用pu_relax()锁的场景是忙等待（也就是死循环等一个事情的发生），在内核里面有大量的代码，比如等寄存器状态：

比如做延迟：

简单来说，你如果在内核里面写了忙等待的代码，都没有在循环里面加个cpu_relax()的话，这基本上是一种比较幼稚的表现。

根据内核文档volatile-considered-harmful，cpu_relax()的描述：

由此可见cpu_relax()至少具备三大功能：

1. 帮着省电；

2. 如果是超线程CPU的机器，可以让渡CPU给其他的线程；因为我这个CPU目前没什么正经事情干，等的时间不如放慢节奏，让别人多干点；

3. 它是一个编译屏障，让volatile变地在内核基本没什么必要。

当然，cpu_relax()的具体实现与体系架构相关，不同的体系架构实现不一样，可能只完成了上面3个功能中的1个，2个而不是全部。

我们看看它在ARM64的实现：

其中"memory"的部分是服务于屏障功能，而前面的yield符合SMT系统让渡的语义。在典型的超线程处理器中，每个超线程不是一个独立的core，所以两个或者多个超线程之间仍然在竞争一些资源，如果其中一个人调用了yield，那么它会在争抢中放慢节奏，而旁边的那个兄弟会抢地更多。

PowerPC的实现则是调节hardware multi-threading的优先级：

当然，硬件如果不具备这种超线程能力的话，cpu_relax()可以简单地是一个编译屏障，比如arch/alpha/include/asm/processor.h中：

#define cpu_relax() barrier()

在arch/x86/include/asm/vdso/processor.h的实现中：

REP NOP这种pause操作既可以省点，有可以避免忙等的CPU疯狂去抢总线访问内存。如果纯粹地不加pause暗示的忙等，疯狂执行指令，应该是很耗电的，忙等中拼命访问内存，总线冲突也大。

总之，不管具体的体系架构怎么实现，忙等里面都适合加cpu_relax()，毕竟内核多数的代码要求是跨平台的。