4.2.1 可扩展性
Simon Kagstrom做了类似的基准测试来比较不同版本的Linux内核（2.0 - 2.6）在1-8个CPU上的可扩展性。他使用邮戳基准测试（译注：Postmark benchmark，一种用来测试文件系统性能的基准测试程序）测试了相对于内核2.0.40的加速比（speedup）（图6）。
基准测试的结果并不令人惊讶，我们可以看到，锁的粒度的越小（译注：原文写做increase，疑有误），系统的可扩展性越好。但是锁的粒度最低可以降到多少呢？
当然，我们不能忽略更细粒度的锁导致的复杂度的提高——执行特定操作持有的锁越多，死锁的风险越大。Linux社区目前正在讨论锁的层次究竟多少才合理（译注：原文“There is an ongoing discussion in the Linux community about how much locking hierarchy is too much”）。锁越多就需要越多关于上锁次序（locking order）的文档，或者是死锁分析器这样的工具。死锁问题是最难处理的。
锁的开销同样不能忽视：CPU并不仅仅在临界区（critical section）上花费时间，获取锁、释放锁同样需要时间。看一下图6上2.6内核和2.4内核在少于4个CPU时的表现：内核的锁多的那个更慢。执行一个临界区的效率可以用方程式式表述为：
临界区内所用时间 / (临界区所用时间 + 获取锁所用时间 + 释放锁所用时间)
如果你把一个临界区一分为二，获取锁和释放锁的时间大致也增加了一倍。
令人惊讶的是，即使第一次尝试就获得锁，一个简单的锁获取损失的性能也会越来越大。要想明白这一点，我们需要忘记那种没有cache的标量处理器模型，看一下现实中的处理器模型是什么样的。
阅读(1642) | 评论(0) | 转发(0) |
