原文作者是Arwed Starke，讲的是锁在linux内核中的应用，我翻译的是锁性能研究的这部分：）
4 性能研究
Linux内核2.0.40共调用BKL（Big Kernel Lock）17次，而内核2.4.30共调用BKL 226次、自旋锁（spin lock）329次、读写锁（rwlock）121次，还有56次顺序锁（seq lock）和14次RCU（后面会介绍这两种同步机制）。
为什么Linux开发人员会在这上面做如此多的工作？原因是粗粒度的锁使得内核在CPU个数超过3、4个时表现的很差（译注：从原文看貌似指的的扩展性，但是从后面可以看出来实际上指的是性能）。一个包含n个CPU的SMP系统的理想性能应该是同类型单CPU系统的n倍，但是这种情形只会出现在所有CPU都在有效工作（doing productive work）时。对一个锁忙等待会浪费时间，锁的竞争越厉害，就意味着等待获取它的CPU越多。
因此，内核开发人员对锁的竞争做专门的基准测试（benchmark），以此来检测哪些锁需要分解，减少对他们的调用。他们在锁变量中加入“锁信息”（lock-information）结构，它包含了获取锁成功次数（hits）、获取锁失败次数（misses）和自旋次数（spins，等待总数）的计数器。每次等待的自旋数（spins/misses）表明了锁竞争的激烈程度。如果数字很大，表示处理器浪费了很多时间来等待锁。
测试锁的竞争程度是寻找（性能）瓶颈的常规做法。Bryant和Hawkes写了一个专门的工具来测试内核中锁的竞争程度，他们用它来分析文件系统的性能。还有人专注于内核2.4.x调度器（已经被完全重写了）中的锁竞争。目前，Linux调度器通常对每个CPU专属的就绪队列操作，它在包含512个CPU的系统上依然表现良好（译注：这句话的意思是说2.4.x的就绪队列是CPU之间共享的，现在为了减少就绪队列中锁的竞争，为每一个CPU都分配了单独的就绪队列，这使得调度器可以在CPU很多的系统上性能更好）。
那些需要访问共享资源的应用会大量的用到锁：比如虚文件系统（VFS）、网络，还有派生很多进程的应用。Edison et.al.（译注：公司名，原文写做Etison et. al.，疑有误）对这几个子系统做了几个压力基准测试，作为如何使用KLogger（内核日志/分析工具）测试锁竞争的一个例子。他们计算了并行编译时自旋时间所占的百分比——Linux内核、Netperf（一个网络性能估值工具）和带有Perl CGI的Apache WEB服务器参与了该测试。
这样的测试可以帮助发现和消除锁的瓶颈。
阅读(1935) | 评论(0) | 转发(0) |
