FreeBSD 8.0展望

FreeBSD的Robert N. M. Watson在回应一封-hackers的邮件时 （Message-ID:
20071125110116.U63238@fledge.watson.org
），对 FreeBSD 的 SMP 工作进行了回顾，并对 FreeBSD 8 进行了一些展望：
目前的绝大多数操作系统，都是从单 CPU 的硬件开始起家的。因此，内核的同步模型，基本上都是针对中断处理程序、 I/O 导致的阻塞所产生的并发，而非真正的并行处理而设计。一般来说，这种模型包括了“禁止中断”，有时还包括“中断优先级”以便处理不同的优先级和选择性抢占，以及用以处理同步操作，如使内核线程进入休眠状态的 I/O 等的简单的休眠锁。正如你已经猜到的那样，这也是 BSD，包括 FreeBSD 开始这些工作的起点。
因此，在操作系统中引入 SMP 支持的第一步，往往就是引入“全局锁（Giant lock）”，使内核在同一时刻事实上只在一颗 CPU 上运行。这样做的目的是在 SMP 硬件上运行时，能够依然使用 UP（单处理器）内核的那些基本假设。这使得用户态程序能够运行在多个 CPU 上，但内核则不能以并行方式运行。在内核中引入这种变动相对而言比较容易，因为它不需要改变整个内核的同步模型，而只需简单地加入全局锁、修改硬件探测和引导代码，处理中断传递、TLB shootdown等等。但是，由于内核无法从并行处理中获益，因此对于高度依赖内核的操作而言，启用 SMP 除了增加开销之外，意义不大。
因此，引入 SMP 支持的下一个步骤，便是修改内核的同步模型，使得它的一些部分能够在多个 CPU 上同时运行，并由此带来性能提升。对于 FreeBSD 而言，全局锁是在 FreeBSD 3 引入的，我们在 FreeBSD 5 中开始将其细化。在 FreeBSD 6 中，内核的绝大多数子系统都已经不再使用全局锁，而在 FreeBSD 7 中，锁的细化进行了更进一步的推进。现在还有一些边角的位置上存在全局锁，不太常用的文件系统、一些较旧的设备驱动，等等，但多数情况下，已经不会再看到正在运行由全局锁保护的代码了。需要说明的是，即使只是将内核中 1/2 的部分中的全局锁细化，也会显著地改善全局锁保护的代码性能，因为锁的冲撞机会减少了。
目前，全局锁已经逐渐被弱化成了保护 tty、 newbus、 usb 和 msdosfs 代码的锁，并且，消除全局锁的工作，已经带来了显著的性能提升。在 FreeBSD 7 中，我们的工作重点，已经从消除全局锁，转移到了优化上锁原语、调度器以及锁粒度上。例如，在 FreeBSD 7 上 MySQL 的性能改进，多数都归功于下面几个有限的变动：


      由 M:N 线程转为 1:1 线程模型。
      对于 sx(9) 休眠锁原语的大幅改进。
      引入了高效的非休眠 rw(9) 上锁原语。
      将内核中文件描述符表的上锁方式改为使用低开销的 sx(9) 原语，以及通过将上锁操作细分为读写两种所带来的改善。
      将 UNIX domain socket 改为细粒度上锁模型。
      由于引入 ule(4) 调度器带来的大幅可伸缩性改善。


在 FreeBSD 8 中，我们将继续对上锁粒度和内核并行性方面进行改进，以更好地在更多 CPU 池中分摊负载。多核、多处理器芯片正在迅速普及，因此多处理器系统的性能非常值得深入挖掘。也就是说，尽管目前我们所做的工作已经取得了相当大的成效，我们仍然需要继续挖掘多处理器硬件，特别是在网络协议栈方面的潜能。
(本文转自
http://wiki.freebsdchina.org/news/2007/freebsd_8_roadahead
)