版权说明:这篇文章原载于2000年1月的DaemonNews。这份版本可能包括了Matt以及其他作者的更新,以反映FreeBSD VM实现的进展。
这个标题实在是一个很自负的说法,我的意思是,我正试图描述整个FreeBSD VM系统,以一种让多数人都能够接受的方式。在过去的一年中,我集中精力于FreeBSD的主要内核子系统中的大量模块,特别是VM和磁盘交换(Swap)子系统,以及相关的NFS代码。我只是重写了所有代码中很少的部分。在VM领域,我做的最主要的重写是针对磁盘交换部分的代码进行的。我的绝大部分
工作是清理和维护,其中包括适度的代码重写,而没有对VM子系统中的算法进行大规模的调整。VM子系统的主要理论基础没有发生变化,而绝大多数与VM相关的功绩应该归于John
Dyson和David Greenman。与Kirk这样有资历的学者不同,我并不想尝试为每一个特性标记特定的人名,因为我经常把他们搞错。
1. 入门
在开始介绍实际的设计之前,让我们来花些时间来介绍维护,并让那些存在已久的代码基础(codebase)进行现代化的必要性。在编程者的世界中,算法总是趋于比代码更为重要。同时,作为BSD的学术传统的一部分,在开始时就对算法设计加以特别的关注也恰好符合这一点。在设计上给予特别的关注的结果通常就是一个干净而灵活的代码基础,它能够被很容易地修改、扩展,或随着时间的推移被替换掉。尽管BSD被某些人认为是一个“古旧”的操作系统,我们这些为之工作的人则认为它更多地
是一个“成熟”的代码基础,其上的众多组件被修改、扩展甚至替换为现代化的代码。它正在进化,而且,无论代码中的某些部分多么地古老,FreeBSD总在接受新鲜血液。这是FreeBSD的一项重要特点,而许多人往往忽视了它。程序员能够犯下的最大错误是不肯学习历史,而这是许多其他现代操作系统中非常常见的问题。NT是一个最好的例子,而其结果是相当可怕的。Linux也不同程度地犯下了许多类似的错误——这些错误足够在BSD开发者中间,每隔一段时间就流传一次笑话。Linux的问题可以简单地归结为,缺乏可以用来比较思想的经验和历史,在不断的代码开发过程中,Linux团队可以和BSD团队一样快捷地找到问题所在。而NT的开发者,另一方面,重复地犯下Unix几十年前就已经解决掉的错误,并且花上几年来修复它们,并且一而再、再而三地这样做。他们最严重的问题是“not
designed here”(此处没有进行设计)和“we are always right because our marketing department
says so”(我们永远是对的,因为我们的市场部门这样说)。我认为不愿学习历史的人是不能被原谅的。
许多FreeBSD设计中非常明显地复杂的部分,特别是在VM/Swap子系统中的那些,是在不同条件下不得不解决的那些性能问题的直接结果。这些问题并不是由糟糕的算法设计造成的,它们来自实际的环境。在平台之间的直接比较中,这些问题由于系统资源受到重压而变得非常明显。在我描述FreeBSD的VM/Swap子系统的同时,读者应始终在头脑中保持两个重要的概念。首先,高性能的设计的重要方面是我们常说的“优化关键路径”。这一原则通常的结果是代码的膨胀,因为它能够让关键路径的代码的性能变得更好。第二,坚固的、范型化的设计在长时间的运行中胜过那些深度最优化的设计。尽管范型化的设计与那些经过深度优化的设计相比,前者的性能在最初实现中可能更差,但范型化设计能够更容易地适应变化的条件,而过分深度优化的设计则无法适应,以至于不得不丢弃。任何得以幸存,并在几年后能够被维护的代码基础,因此都必须
从一开始就进行正确的设计,即使它的代价是少量性能上的衰退。20年前,人们曾认为使用汇编语言要好于高级语言,因为它能够产生快10倍以上的代码;而今天,上述论点的错误是非常明显的,因为算法设计和编译技术的发展已经大大降低了高级语言与汇编语言的差距。
|