摘要
本次采访中(2002年10月), Robert和我们讨论了Linux抢占式内核的现状, 他最近参与0(1) 级调度器开发的情况, 以及他在 VM overcommit方面的工作。他还对linus使用Bitkeeper，Linux的未来以及最近在Ottawa举行的kernel summit会议发表了自己的看法。(2003-09-22 09:51:38)
By Anlin
Kernel trap在2001年10月对Robert love进行了第一次采访；之后不久, 他的抢占式内核补丁被收入2.5系列内核；他在内核开发方面一直很活跃。最近，他再次接受了我们的采访。
本次采访中, Robert和我们讨论了Linux抢占式内核的现状, 他最近参与0(1) 级调度器开发的情况, 以及他在 VM overcommit方面的工作。他还对linus使用bitkeeper，Linux的未来以及最近在Ottawa举行的kernel summit会议发表了自己的看法。
Robert现在在加州为MontaVista公司工作，但8月底他将回到佛罗里达州立大学继续他的大学三年级的学业。请继续阅读我们采访的全部内容：
//JA for Jeremy Andrew @ KernelTrap
//RL for Robert.M.Love
JA: 我上次访问你到现在已经有8个多月了, 那时你已经对Linux内核做出了令人印象深刻的贡献。几个月前你的抢占式内核补丁被收入2.5 版内核的开发树，而且你投入很大精力参与了O(1) 级调度器的开发工作。 除了这些以外，您在 Gainesville的工作和生活怎样呢?
RL: 都还不错。4月份我完成了在佛罗里达大学的第二年学业。我很喜欢大部分课程，尤其是数学。8月底我将开始第三年的学习。
摄影是我的爱好之一， 我买了新的照相机---Canon Elan 7e。这是一个SLR 35毫米 beast的单反相机(但不是数码的)。我拍了很多照片，从中获得了很大的乐趣。
一月份我就开始在MontaVista， 一家嵌入式Linux公司，工作了。 我在实时和性能工作组做内核hacking方面的工作。 MontaVista 是开源软件的坚定支持者，因此我可以同时为社
区的很多项目工作。 公司一直对抢占式内核很有兴趣，这一直是他们的开发项目(note: 抢占式内核最初是由Monta Vista提出并初步实现的)， 而且他们也支持我对2.4 和 2.5 版内核的维护工作。
JA：听起来您可以做自己喜欢的工作，并可以因此得到报酬？
RL: 我真的很幸运。
JA：您提到Monta vista是一家嵌入式Linux公司， 但是我必须承认，除了他们对抢占式内核的贡献之外我对他们并不是很熟悉。 您可以更多介绍些他们的工作吗?
RL： Monta vista为开发者提供了一套开源的基于Linux的嵌入式系统的解决方案。 对于着眼于嵌入式产品的开发者来说， Linux是一个广泛的选择。 我们提供了一个产品和多样
的服务来满足他们的需求。
JA：这个夏天您准备怎么渡过？
RL：在学期中我通常会兼职，但是这个暑假我会在硅谷为Monta Vista作全职工作。 这是一个非常值得的经历。这儿我有一辆车，所以我可以借着这个机会去旅游。北加州真的很美。
JA： 来这儿以后您去了哪些地方旅游呢？
RL： 我在south bay 居住和工作，所以我花了很多时间在附近游览。我经常去 San Francisco， 也去过 Santa Cruz 并且徒步穿过山谷附近的山脉。 我很喜欢那些大学城，像 Stanford所在地 Palo Alto和 UC Berkeley 所在地Berkeley。我还去过Yosemite ，很喜欢那里。
JA：回到您在内核方面的工作。 您是什么时候得知您的抢占式内核补丁将被Linus收入2.5 的开发树的？
RL: 当Linus说 "Ok" 的时候 :-)
糟糕，我几乎想不起来了。我们曾经讨论过这个问题并且这也常常在社区中被提出来。我给了他针对2.5.4-pre5 的补丁，他提出了很多问题，这些问题在我后来的一个补丁进行了处理。
瞧，结果就是，2.5.4-pre6 有了一个抢占式的内核！
JA：作为Linux台式机用户，我很高兴听到您的补丁被采用了。 但是，我仍然记得不久前争论中，很多人不赞成抢占式内核应该成为Linux内核主干(mainline)的一部分。您从其他的内核hacker那里得到的反映如何？
RL： 各式各样的。有些人很喜欢这个而且在为进一步的增强而工作，有些人不喜欢，其他的则持中立的态度。 最重要的家伙(Linus)很喜欢这个；而且我也从两个最具天才(我的个
人看法)的内核hacker Andrew Morton和Ingo Molnar那里得到了支持，对此我十分感激。
JA：现在您对已经被收入mainline development tree的补丁做多少维护工作呢?
RL：比还是作为外部补丁的时候少多了。 在此之前我要花很多的时间跟踪开发树，保持事情的同步并发布补丁。现在我则不必担心类似的事情。实际上是其他的补丁要注意和抢占式内核保持一致。
JA：抢占式内核增加了哪些复杂的因素呢？
RL：有per-cpu数据的问题。由于内核已经是可抢占式的了, 我们有一个规则是内核代码不能假定当前使用的cpu不会被其他代码夺走，这也是被抢占的结果。因此，必须依靠per-cpu
数据运行的代码必须确定抢占被临时禁止。
JA：内核的哪些部分必须因此禁止抢占呢？
RL：举个例子吧, 比如一个图片, 就值数千本 jacky handy书,
int cpu = smp_processor_id();
extern stats[NR_CPUS];
do_stuff(stats[cpu]);
more_stuff(stats[cpu]);
以上的代码中, 因为有了内核抢占( kernel preemption)，你可以在任何地方进行抢占。当重新调度时，你可能在使用另外一个cpu并且'cpu'的值不再指向当前的cpu了。 这样并不好。
解决方法是：
int cpu = get_cpu();
extern stats[NR_CPUS];
do_stuff(stats[cpu]);
more_stuff(stats[cpu]);
put_cpu();
函数get_cpu()和put_cpu()返回当前的cpu值, 但同时也禁止了抢占。需要注意的是只有当前没有锁并且允许中断时才需要做这些，并不是每次使用都会产生问题。我们已经修正了所有已发现的问题.须注意的是以上的方法在单处理器系统中可能造成问题，因为单处理器的数据是“隐式锁定”的， author可能因为不能在同一个cpu上再次读入数据（执行代码）而没有对数据进
行保护。抢占改变了这一切，因此你可能需要禁止抢占。
JA：全部的抢占式补丁都被收入2.5内核了吗?
RL：是的，而且2.5包括了很多2.4的补丁没有收入的变化。2.5还包括了对当前多数处理器结构上内核抢占的支持，体现了支持该补丁的开发者的产生。
JA：2.5现在支持哪些处理器体系结构呢?
RL: ARM, I386, PPC, sparc64和x86-64. Monta Vista已经为2.4提供了支持SH和MIPS的补丁并且这些也可以很方便地进行移植。
JA：除去对额外处理器结构的支持, 2.5的内核抢占式补丁还有哪些2.4的补丁不具备的呢?
RL：我们改变了一些补丁的工作模型。总的结果是一样的，但是实现上有了一些改进。
具体的说, 我们把一些preempt_enalbe()宏移入prrmpt_schedule() 从而减少了一些行间代码。
preempt_enable()在每个spinlock中都是inline的，这减少了目标代码的长度，尤其对于RISC结构的机器。 其次, 我们把preempt_schedule() inline进entry.S 的中断返回路径。我们可以在两个时机进行抢占调度：中断处理完成后（这是一个理想的时机，因为通常中断会唤醒一个进程并且置need_resched标志）和某个锁的释放后。对于中断处理方面的抢占，我们在entry.S的返回代码里加入了汇编。这些代码做些 preempt_enable()之类的检查而后调用preempt_schedule()，如果必要的话。preempt_schedule()再调用 schedule()。我们只是专注在返回路径中preempt_schedule()的逻辑以避免某种重定向。
除此之外，还有一些其他方面的小的改进…
JA：您未来对Linux内核抢占有什么改进计划呢?
RL：这里有一些我或者其他人正在做的事情…
Ingo Molnar, Dave Miller, Linus和我一直在tossing around一些补丁来移除整个local_bh_count和local_irq_stat的概念（大致的讲，就是一个关于有多少个中断或者BH正在进行的计数）并且将他们封装入preempt_count。这将会使我们能够将preempt_count作为
一种接近原子性的计数器使用并减少很多代码。
我认为仍有一些代码路径可以更好地利用抢占式内核，我会寻找使这个新的视角得到应用的地方。最后，也是惯例的是：减少锁持有的时间以减少延迟。
JA：您的scheduler hint补丁得到了多少回馈信息呢？
RL：不是很多，而且遗憾的是，最有用的回馈却是在list(note: lkml)之外得到的。我并不会过分相信scheduler hints是一件好的事情。它们在Solaris上表现很好， 但是对我来说只是一个提醒我scheduler需要fixing的标记。 换句话说, 它们是一种band aid。唯一我认为有
些用处的是HINT_TIME， 这是Solaris系统的成功之处。困难在于分是实现公正以及判定我们所增加的复杂性是否值得,或许不。
JA：您可以描述些正在做的关于O(1) scheduler的工作吗？
RL： 当Ingo第一次将他的scheduler张贴出来的时候，它设计上的完美给我留下了很深的印象。 我对Ingo作为一个程序员和结构设计者有着极大的尊重，但我仍感到十分惊讶。我
开始对其做出贡献，给出我的认识并修正bug，让抢占式内核在新的scheduler上工作。最近, 我完成了task affinity cpu系统调用, 实时的增强, 可配置的优先级并编写了些相关的文
档。 现在Ingo和我共同维护这个scheduler， 我还将更新的内容应用到Alan的 2.4-ac树上并且维护stock2.4树的o(1) scheduler补丁。
JA：O(1)对Alan的2.4-ac树的backport是我仍使用它的一个主要的原因。加上你的抢占式补丁和rmap，它工作地非常好。说句老实话，我有很长时间没有运行其他的程序了，甚至都忘了它的样子。与2.5的scheduler相比，Alan的 2.4-ac树中的scheduler有什么缺少的吗？
RL： 在2.5中已经证明相当稳定的代码移植到2.4-ac的过程肯定会有延迟，Alan合并了它们，但是并没有出现过于特殊而无法解决的情况。 2.4 将会和2.5保持合理的同步。
JA：您对2.5内核开发的进展是否感到高兴呢？
RL：是的，整个开发过程看起来进行得不错。我给Linus的所有代码都成功地被接受了，这总是一件好事情。
JA：对于2.5您仍然希望Linus收入的有影响的补丁有哪些？
RL: 非常不幸运的是还未收入的补丁中，只有很少是未决定(pending)的。现在我更感兴趣的是那些我们希望可以在万圣节冷冻期（Halloween freeze）前完成的事情。 但愿SCSI层可以引入一些sanity，我还祈祷tty层更多的工作。余下的Patrick Mochel's优秀的设备模型和driverfs代码是我非常欢迎的。
最后, 我希望Andrew Morton能够将Rik 的 rmap vm分成逻辑块并由Linus掌管它们。 期望这样所有的VM开发者都可以改进它，我自己也很喜欢为它工作。
JA；您曾经单独在虚拟内存上花过时间吗？
RL: 一点点。虚拟内存是我感兴趣的方面之一，但是我还没有贡献很多代码。实际上, 我围绕rick的 rmap vm做过一些工作；现在，我为rick's vm和 the stock 2.4 vm两
方面做strict vm overcommit的工作。严格的虚拟内存overcommit工作是一个有趣的挑战。其中大部分的工作是alan cox为他的2.4-ac树做的。 现在，Linux将会高高兴兴的overcommit memory –也就是说，在没有空闲内存作为保证(back)的情况下，内存分配也会成功。这个策略通常工作良好，因为一个系统往往拥有大量自由的内存。更进一步的说，很多内存的分配并没有充分地利用或者很快就被释放了。因此 overcommit减轻了虚拟内存系统的压力，从而减少了页交换的频率。现在我们已经成功完成了一种基于简单的启发式规则的分配方法，这会在允许足够的 overcommit
"fixing"有两层含义。首先，我们必须严格地计算分配的内存块的大小。举例而言， 一个在很多进程间共享 的"Copy On Write" 的页只占用一页的内存， 因为这就是它物理上消耗的。但是在任意时刻，一个进程都可以对此页执行写操作从而不再共享它而是拥有自己的拷贝。因此，我们需要对每一个可写的共享实例计算一次而不是总共只计算一次.其次, 既然我们已经有了一个合适的accounting, 我们就必须制定一个严格的规则。比如，"committed memory will not exceed swap"。有了这些改变, 内存过度使用的情况就不会发生了。所有失败的情况都被归结到分配函数上
(fork,mmap,malloc,etc)。对内存的访问也不会造成OOM(Ouf Of Memory) kill的情况了，如果内存块已经被分配，它就应该是存在的。
JA：听了您的解释以后, 我感到不解的是为什么现存的虚拟内存系统不采用严格的虚拟内存overcommit呢? Overcommit听起来是一件好事, 是不是它存在什么不足?
RL：是的, 主要有两点：(a) 额外的accounting. (或许是不足考虑的吧。实际上, 无论严格的overcommit是否存在, 我完成的部分都进行accounting的工作) 。(b) 禁止overcommit之后, 虚拟内存系统的压力就会提高而且页替换频率也会跟着增加。
JA：您曾提到对于对称多处理器scalability的兴趣，那么对于Linux对称多处理器scalability的未来你有什么看法呢？
RL：那就看你想scale些什么了 :-)
2到4个处理器的现在的情况(note: Linux运行于2~4 CPU的smp系统之上)是很理想的， 或许我们可以再顺利地扩充一些。但是继续扩充到无限则会将Linux置于一种扭曲的混乱状态。
JA：您还提到了对锁机制的兴趣, 能否举些例子？
RL: 你看，我并不知道自己为什么会对锁机制感兴趣的。大多数人或许并不会认真考虑他们所使用的锁是如何实现的。但是我读一个操作系统时做的第一件事就是理解它的锁机制。 我想或许我就是这么古怪吧…
总之,我对于我们实现的各种原语(primitive)以及它们的使用方式都是很感兴趣。我们已经实现了一个非常棒的轻量的(lightweight) spinlock。在内核summit会议上，我曾提出要实现一种新的轻量级的互斥锁，也就是一种没有我们现有信号量的复杂特性的二进制信号量，或许具有 spin-then-sleep行为。
JA：2.5的锁机制相比以前的内核来说有什么改进呢？
RL: 它实现地更好, 尤其是在VFS层。我对于2.5做的第一件事就是把BKL(BigKernelLock)从高层的llseek()函数中去除，把它放入单独的llseek实现中去。这样现在每个函数都可以决定它需要哪些锁了。因此，普通磁盘操作使用的llseek就只需要i_node信号量了。
这种 “锁下推”(pushing locks down)工作在 VFS层的很多VFS例程(methods)中继续。 其他领域的工作也在继续, 尤其是移除BKL的工作。当rmap被收入时, 我知道Bill Irwin有一些可以减少锁竞争的补丁。Andres Morton也做了一些在VM中减少VFS层高度竞争的工作。
JA：那么Linux的锁机制与其他操作系统, 比如FreeBSD和Solaris的比起来怎样呢?
RL: Solaris 要比Linux grain得好很多(note:具有更细粒度的锁)，它在多于64个cpu的环境中仍能良好地工作。因此，Solaris有低端为高端折中的名声。 FreeBSD在它的5.0开发树中引入了一些有趣的锁构造，但他们也只是刚刚开始grain他们的内核，他们似乎把目光都放在高端的具有 scalability系统上。
JA：从2.5向上看,您希望下一个内核的开发中包括有什么工作呢?
RL: tty层的重写。哈哈。 我不能想得那么久远。我很希望看到内核得到整理，旧的cruft被移除以及类似的事情。而且有一个只是使之更精炼的发布版本。
JA：您对于Linux内核的发展方向感到担忧吗?
RL: 是的，我常对高层工作对普通情况造成的影响感到担忧。你或者扩展到128个cpu或者只是在一两个cpu上优化运行。你或者对一些少数运行的任务进行优化或者运行着上千个数据库线程而无法进行优化。
我只是对前者(scalability)进行了改进，所以你可以想象出我所担心的事情。这也是我们大多数人都担心的。
由于Linux内核演进（evolutionary）性的设计，状况会变得更糟。 我很担心我们只是对出现的问题进行hacking 和rehacking，而这将会是最大的问题。
JA：您预计我们什么时候会看到2.6版本的发布?
RL：18个月，你赌多少(place your bets)？
JA：一年半看起来很长, 尤其在几个月前的代码刚freeze的情况下。为什么您认为我们要花那么长的时间才能看到2.6的发布呢？
RL：我曾看到过早至2003年初的预测， 那就只有几个月的时间来达到稳定期了。 就过去的历史而言， 达到稳定状态所花费的时间要比 特性波动期("the flood of feature" )长得多。
我预测一个现实的日期：2003年夏天。距离现在有一年的时间。考虑历史因素，我会把这段时间加长到18个月，或许稍微少一些；但绝对是距离冻结期(freezing)有一年的时间的。
我更关注2002年10月31日的实际冻结，如果我们赶的及的话，我们可以有足够的时间来使内核达到稳定状态。不管是一个月，还是一年。
JA：除了内核以外近期您还对哪些开发计划感兴趣呢?
RL：GNOME2是令人感到惊奇的！
Metacity (一个和gnome2兼容的窗口管理器) 很漂亮而且速度很快，Havoc 真是个天才！
JA：您对于Linus采用bitkeeper的决定以及其后长时间的争论有什么看法?
RL：如果它可以让他(linus) 效率更高而且更高兴， 那么我就喜欢它。 我希望它是开源的吗？ 当然了。但是它很有效而且是当前最好的解决方案，所以我对此并不抱怨。
JA：那您用BitKeeper来管理你的内核开发工作吗?
RL：没有。我用 diff, patch, grep, find和大量的目录。
JA：一个幽默的描述。那么您为什么不选择这种基于更加正式的管理系统的策略呢？
RL: 我认为很多内核开发者也是选择这种方式吧。 或者类似的是他们使用CVS来保存数据，但是大量的脚本文件或许是最普遍的代码管理工具了。我选择它是因为它适合我。
JA：您最近参加了在Ottawa举行的内核Summit会议，您觉得会上最有趣的是什么？
RL: 内核开发会议本身就是很有趣的. 这是一个为期两天的只有被邀请才能参加的会议。有大约60名核心的内核开发者出席。上次我们谈话时，你问我是否遇到过其他的内核开发者。虽然这不是一个如我预想的petting zoo，现在我仍可以说我正巧遇到了他们所有的人。
一些好的议题包括Patrick Mochel的driverfs和James Bottomley的SCSI。Patrick有包括占统治地位的driverfs开发计划。SCSI需要很多的工作，并且James有希望成功对其进行领导。我曾希望关于VM的争议应该是有争议的（当然最终是有回报的）, 但Linus在一开始就明确表示他希望在2.5中给rmap一个机会，对此我感到很欣慰。最后的谈话是由Ted Ts'o 领导的，集中于内核发行版的管理。我们决定了现在声名狼藉的freeze date，2002年十月31日。Dave Jones也被惩罚了，被给予了帮助Linus进行feature freeze工作的机会。会议最有价值的部分, 则是非正式的"hallway discussion"以及在Ottawa的一些俱乐部里进行的交谈。 面对面交谈确实是一件很值得的事情, 我认为从中可以得到很多益处。
JA：您还参加了内核开发者会议之后的Ottawa Linux 会议…..
RL: OLS也很有趣。这是一个更大的群体，大概有500人左右。 大会的话题也是以内核为中心的。这对我来说很棒，虽然我很希望讨论不同的话题。尽管这样， Havoc Pennington仍然
做了一个很棒的关于GCONF的演讲。OLS的非正式的部分也是很有价值。内核开发者会议恰巧在OLS开始前结束，所以大多数的内核hacker也出席了OLS，因此我们可以继续我们的讨论并认识很多新的朋友。
JA：您还有要补充的吗？
RL: 激光是由光汇聚成的，不是由声音。
我们应当去获得普通用户的看法。
JA：非常感谢您再次接受我的采访. 您对Linux内核的贡献一直集中在我感到很有趣而且用处的领域。我将很乐意看到您的兴趣将会把您引导到哪里。
RL：谢谢。 我也很高兴和你谈话。 Take care.
--------------------------------------------------Related Links:
英文原文来自: http://www.kerneltrap.org
Robert Love's Home Page - (http://www.tech9.net/rml/)
Robert's Linux Page - (http://www.tech9.net/rml/linux/)
Robert's kernel.org FTP Directory - (ftp://ftp.kernel.org/pub/linux/kernel/people/rml)
MontaVista's Home Page - (http://www.mvista.com/)
