摘要
本周，KernelTrap采访了当前负责维护可抢占内核补丁的Robert Love。他使用Linux已经7年了，为现在的内核作出了很多贡献。他的话，是这一切的最佳描述...
JA: 请谈谈您的个人情况...
RL: 我现在是Gainesville佛罗里达大学计算机与数学专业的学生，家乡
在Ft. Lauderdale, FL(note: FL for Florida)。我还没结婚，但
有一个很不错的女朋友。我编程的爱好在于操作系统和数学/科学计算。
JA: 何时毕业，毕业后有什么计划?
RL: 2004年。但我还是想留在学校里继续读书以获得更高的学位，非凡是
经济仍停滞在当前的状况(remains as-is)。
JA: 来自 Ft. Lauderdale, FL.的什么地方?我住在那里的Lauderhill。
RL: 我出生于Pembroke Pines，在那里长大。
JA: 您什么时候开始接触Linux?
RL:
第一次在我的PC上运行Linux是在1994年年末，当时用的是1.0版的内核；
这也是我第一次真实的Unix体验。我的那台PC是386SX（感谢妈妈），在
转而运行Linux之前，它之上运行的操作系统是Windows 95 beta。我在
使用2.0版时进步更大，从2.2版开始则完全转向了Linux，此后一直只使
用Linux。
我转向Linux有一个显而易见的原因: 我相信Linux是一个强大健全有着优
秀应用软件的系统。然而更重要的原因是它使我能对系统以及围绕它的社区
的有充分的接触。
JA: 你可不可以描述一下1.0版内核相比现在的2.4版的几个要害区别?
RL: 假如1.0和2.4有几页代码是相同的，我将会非常惊奇。两者没有任何
相同的地方。
JA: 安装和使用1.0版的内核是什么样的情形，有哪些软件可以使用?
RL: 幸运的是，1994/1995年，Linux发展良好。那时SLS和Slackware
都提供了全功能的发行版。我最初使用Slackware2.0。那时你必须以磁盘
集(disk sets)的形式将Linux安装文件下载到磁盘上，可能你现在仍这么
做。我记得磁盘集A是核心，磁盘集N提供网络支持，等等。那时Linux已经
支持网络了，X也可以使用(XFree86 2.0)，也支持很多硬件。
和今天相比，最大的问题是缺少文档，安装又非常复杂。我记得起初我曾因
为没办法让PPP用Linux；假如那时我可以使用PPP的话，我可能早就转向
Linux了。
JA: 您为内核做出的贡献有哪些?
RL: 目前我主要的时间是花在可抢占内核补丁的维护上。这个补丁可以使低
优先级的进程被剥夺，即使它当前处于核心态，结果是改善了系统的响应时间。
这个补丁最初是MontaVista-一个伟大的公司-的杰作，所以我和他们以及这
个社区(Linux社区)的其他成员密切合作。这是一个很有趣的项目。我们正把
目标是将它加入到2.5版的内核中。
我的工作是非常随机的。修正bugs，优化，作一些旨在使系统简洁的清理。我
也写过i815和AMD761 AGP GART的代码，也维护着其他一些的零碎的补丁。
JA: 为了使得内核可抢占，您的补丁对内核作了哪些必要的修改?
RL: 我们的模型是当内核不被锁定时，任何时刻都可被抢占。根据这个设计，
当一个事件激活更高优先级的进程时，系统将会剥夺当前正在运行的进程，转
而运行这个更高优先级的进程。
我们必须修改entry.S中的中断代码来避免某些情况并能在中断处理过程返回
时发生抢占。但是我们不能在临界区内抢占，这和在SMP环境下的临界区中不允
许并发的道理相同，所以我们防止了持有自旋锁(spinlock)时被抢占的情况。
bottom half handler和scheduler同样需要修改，以保证在它们运行时不
发生抢占。
JA: 时至今日，您认为您的补丁的稳定性如何?我的所有工作都在一台独立的
Linux服务器上完成，我不断为它升级内核和软件。改善系统的响应固然有吸引
力，但您有没有考虑过对一台不间断运行的服务器来说，补丁是否足够稳定呢?
RL: 补丁非常稳定。我可以非常有信心地鼓励任何人来使用它。我们有很多用户，
收到了很多反馈。我想我们已去除了明显的漏洞（bugs）。我在自己的主系统中
使用这个补丁。
最重要的是我们知道它的设计和实现是正确的。使用了我们最新的补丁之后，我
感觉我们已解决了所有的问题。
JA: 在您看来，系统响应时间上的改进有多明显呢?
RL: 非常明显。
我们曾经记录过200%的系统延迟方面的提高。安装了可抢占内核补丁后，系统的
平均延迟大约为1ms，不会超过10ms。仍有些长时间的锁占用会影响响应，导致
有些延迟达到100ms甚至更长。幸运的是这些情况只在特定情况下出现，就像切
换虚拟控制台(switching VCs)。
JA: 现在还有另外一个最终目标相同的补丁(由Andrew Morton维护)，跟您的
有何不同?
RL: 这两个补丁所针对的问题都是内核是非抢占的。也就是说，处于内核态的任
务会一直运行，直到其运行结束或主动交还控制权。假如用户态事件在内核操作
的时段发生，用户程序必须等待内核完成本次运行。这个等待就导致了系统延迟，
而它(系统延迟)正是我们要去改进的。
Andrew的低延迟补丁在内核的各策略点(note: Andrew认为可能引发长时间延
迟的点)加入了条件调度调用(conditional scheduling calls)，这些调度
非常有效地使长时间的内核操作作出让步:"我很乐意让别人先运行。有没有想运
行的任务啊?假如有的话，就先运行吧!"这样拆分了长时间的操作，降低了相应
内核运行点的系统延迟。
抢占式补丁工作机理则很不一样。它修改内核本身以答应核心代码被抢占，所以
上述问题甚至根本不会存在。假如有任务需要运行，它就会运行，系统响应从中
受益(note: 减少了响应时间，改善了系统响应)。
JA: 在最新的lkml 中，您提到有可能将两个补丁组合起来。这是您现在的工作
方向吗?
RL: 这当然是需要考虑的。由于我们不能在系统被锁定时抢占(note: 即使内核
打了可抢占补丁)，长时间的锁对系统延迟来说是一个很大的威胁。锁的延时很可
能就成了那段时间系统的延迟。
一种解决方法是像Andrew的补丁所做的那样拆分这些锁。这将成为合并部分他的
补丁到抢占式补丁的目的，或者更现实一些，做一个他的低延迟补丁的抢占式版本。
他的patch中的在内核被锁定时的任何条件调度都可能是有用的(note: 对于改进
我们的patch)。
这个方向(note: 拆分长时间的占用锁)的第一步是标识出长时间被占用的锁，这
正是抢占统计(preempt-stats)补丁所做的。这种方法衡量禁止抢占的时间并报
告导致这个结果的锁。
以上仅仅是针对长时间锁的一种解决方法。
JA: 您所标识的内核的哪些部分会出现这种长时间锁呢?
RL: 控制台层，过去可能出现非常长时间的锁，幸运的是，最近
Andrew Morton修正了很多这方面的问题。Frame buffer的代码会屏蔽中断很
长时间以避免往其输出太多。假如滚屏太多，延迟甚至可能达到500ms。切换虚拟
终端的情况也很糟糕，blkdev_close()会很长时间的占用一个锁。有些模块操作
很耗时。假如VM开始出现颠簸(thrashing)，它也会导致很多延迟，因为颠簸时
VM会占用一个锁。VFS也有一些长时间占用的锁。
JA: 将您的补丁加入2.5可能性多大?会有哪些阻碍?
RL: 这完全取决于Linus先生对这个补丁的看法以及其他hacker的意见。Linus
之前曾表示他对这个想法很感爱好，我希望他的爱好可以帮着将这个补丁加入内核。
作为一个独立的补丁，我们有很广泛的用户基础，这显然非常有用。我们收到了很
多反馈，包括一些显示这个patch对系统带来巨大的改善的评测。
反对意见是，抢占式内核降低了系统的吞吐量。这是要害点，也是我们需要非凡说
明的。现在的多数测试显示了0~5%的吞吐量损失--我想相对于200%的响应提升这
是值得的!另一些测试则显示了系统吞吐量的提升，因为我们更好的排列了系统的处
理流程(thread better)。退一步，对于那些无法接受吞吐损失的系统，抢占式
内核只是一个可选。
JA: 您开发时主要使用哪些工具?请描述一下您的环境、计算机和使用的方法。
RL: 我使用最多的主机是PIII-733(384MB内存+U2W SCSI磁盘)。我也有一台
IBM ThinkPad，还有撒满一地的旧工具(not
