本文译者：
康华 ：主要从事 Linux 操作系统内核、虚拟机、Linux 技术标准、计算机安全、软件测试等领域的研究与开发工作，曾就职 MII-HP 软件实验室 、瞬联软件公司/MOTOROLA，现就职于Lenovo研究院 。其所合写的Linux专栏见http://www.csdn.net/subject/linux/。 如果需要可以联系通过 kanghua151@msn.com （MSN）联系他。
Kevin 将继续他的实时之旅，这次他要着重分析如何通过改造Linux内核来为应用程序带来实时性能。
在2002年的1-2月发行的嵌入Linux月刊中，我们探讨了有关实时和Linux的基础问题。而这次我将精力花在改造Linux内核来为应用程序带来实时性能这个主题上。到目前为止，工作的重心集中在提高内核响应速度——通过减少抢占响应时间缩短系统响应时间，因为我们知道抢占响应时间在Linux中耗时较长。
通过改进内核——仅仅是剔除一些标准内核的功能——并不去改变或增加内核API，应用程序就可以获得更快的响应速度。这样做优势明显，因为ISVs(独立软件开发商)不需要为不同的实时要求开发不同版本的系统。比如，DVD播放器可以在一个改进过的内核上更稳定的运行，而它不必知道该内核是经过改进的版本。
背景和历史
自2.2版本内核发布以来，内核抢占成为一个热门话题。Paul Barton-Davis 和 Benno Senoner曾给Linus Torvalds写了一封信该信后来追加了许多人的签名)，请求在2.4版本内核中显著降低抢占延迟时间。(
他们需要Linux性能上能满足播放音频、音乐以及MIDI的要求。Senoner开发了一套基准软件（benchmarking software）测试2.2版本内核（以及后来的2.4版本），在最坏情况下发现抢占延迟高达100毫秒(参考。 对于音频应用程序来说，这么长的延迟时间显然是无法接受的。因为经验显示系统响应时间只有在几毫秒内才能满足音频应用程序的需要。)
有两个补丁包为内核提供了相当不错的抢占响应速度提升。Ingo Molnar (来自 Red Hat) 和 Andrew Morton (来自Wollongong大学) 两人都开发了内核补丁，这些补丁为内核中长代码路径片段插入了抢占点。你可以在这里这里发现Ingo Molnar的补丁包 ，或在这里找到Andrew Morton的补丁包。
另外，Morton还提供了测量响应速度的工具，比如测量内核忽视请求时间长度等，有关详细信息在他的快速响应补丁网站上可以找到。
目前，至少有两个组织开发了抢占式内核，为内核抢占问题提供了更基础、更强大的解决途径。
要明白这些性能改进都必须依赖给内核打补丁，但是打补丁后的内核就不再兼容其它标准内核了，比如抢占式内核需要修改自旋锁的代码，这时如果一个驱动程序的二进制执行文件如果不采用修改过的自旋锁，那么很可能无法正常抢占。所以改造内核时一般都需要内核源代码并重新编译内核代码。值得一提的是，使用模块化的Linux驱动程序是使得源代码兼容的一个有效方法。我们不赞成仅仅发布驱动程序的已经编译的二进制文件而没有源代码，因为这样作既缺乏兼容性保障也不符合开源精神。
改进
各种各样对内核的改进能够为应用程序透明地提供众多好处。比如，提高内核的抢占性主要通过抢占式内核或是添加抢占点着两个途径。从内核角度进行改进可以使得应用程序不用做修改就能获得高的响应速度。
透明性也应该考虑是否改变对内核来说也是透明的，换句话说就是，是否采用的方法能自动跟踪内核的改变。Molnar和Morton提出的插入抢占点的方法需要测量新内核中的调度响应时间，并且在此基础上插入抢占点到合适位置。
相反，如果在SMP锁定基础上创建抢占式内核,则可以自动、无须修改地过渡到新内核。而且如果在SMP-锁定机制中实现抢占性，则当内核开发者提高SMP锁定粒度（granularity）时，也同时会自动提高抢占粒度。我们会看到SMP锁定将粒度稳步提高，因为SMP不断扩张必定需要不断提高锁定粒度。
正是由于这种新引进的SMP锁，内核抢占才自2.4版本或更新（实际在2.6才正是支持）内核后被正式实现。而早期内核缺乏SMP锁。
抢占式内核的另外一个需要强调的重要优势是它使得代码——但代码不会发觉——可被抢占，比如，驱动程序开发者不必为要使驱动程序可被抢占去编写任何特殊代码，驱动程序的代码能在必要时被抢占，除非驱动程序持有锁。所以在内核其它部分，编写优良的SMP安全（代码中不存在多处理器并发访问共享资源的危险）的驱动程序将自动受益于抢占式内核。而另一方面，非SMP安全的驱动程序可能不能和抢占式内核和谐工作。
也许有人会发觉，只要某些驱动程序没有请求锁，内核代码就可以调用它。比如我们使用MontaVista的抢占式内核做简单测试中发现，动态装载的驱动程序中read()和write()函数都可以正常被抢占，但是函数init_module()、open()和close()却不能。这意味着如果一个低优先级的进程执行操作open()或close()，那么它有可能被一个新唤醒的高优先级别进程推迟抢占时机。
实际上，开发者最好去测量响应时间，因为即使使用抢占式内核，我们也有可能找到有那些代码片段持有锁的时间超过了应用程序允许的长间。
比如MontaVista, 提供了一个抢占式内核，对那些长期持锁的代码片段插入了抢占点，同时也提供了测量工具，以便开发者可以测量它们实际应用程序和环境的抢占性。
责任编辑 webmaster
发表评论 
打印本文
推荐本文
加入收藏
返回顶部
关闭窗口
