走向 Linux 2.6 | ![]() | 英文原文 | ![]() | |
![]() | ||||
![]() |
![]() |
走进下一个新内核的精彩之作
Anand K Santhanam (asanthan@in.ibm.com) 即将发布的新的稳定的内核支持更多类型的处理器,并且可靠性和可扩展性得到了提高,因而将推动 Linux 得到更广泛的应用。在这里我们将重点介绍一些不同程度的变化,并给出部分代码样例。 Linux 内核的开发已经经历了一个漫长的过程,最初是 Linus Torvalds 于1991年发布的原始的0.1版本,这个版本中包括一个基本的调度器、IPC(进程间通信)和内存管理算法。而现在它已经是一个以往操作系统的实用的替代品,在市场上表现出了强大的竞争力。越来越多的政府机构和IT巨头的注意力正在转向 Linux。从最小的嵌入式设备到 S/390,从手表到大型企业服务器,Linux 现在几乎可以用于所有的地方。 Linux 2.6 是 Linux 开发周期中的下一个主要版本,它包括了一些强有力的特性,这些特性旨在改进高端企业服务器的性能和支持越来越多的嵌入式设备(要了解更详细的关于 Linux 2.6 对大型的、小型的以及多处理器系统支持问题的分析,请参阅参考资料一节中到 Joseph Pranevich 的“Linux 的精彩世界”的链接)。 本文为关注 Linux 的用户分析了 Linux 2.6 的一些重要特性,并且讨论了驱动程序开发人员可能会感兴趣的多方面的变化。 Linux 2.6亮点 在本文中,我们分析了 Linux 2.6的一些最引人关注的特性,但是仍有很多值得关注的变化,包括增强的内核核心转储、快速互斥支持、改进的I/O子系统,等等,在这里我们不能全部讨论。在侧栏中总结了其中一些,其余的我们在参考资料一节中给出了链接。 新的调度器 在2.4版本的调度器中,时间片重算算法要求在所有的进程都用尽它们的时间片以后,它们的新时间片才会被重新计算。这样的话在一个有很多处理器的系统中,当进程用完它们的时间片以后得等待重算(以得到新的时间片),从而导致大部分的处理器处于空闲状态;这将影响SMP的效率。除此之外,当空闲的处理器开始执行那些时间片尚未用尽的处于等待状态的进程(如果它们自己的处理器忙),会导致进程开始在处理器之间“跳跃”。当一个高优先级进程或者交互式进程发生跳跃时,整个系统的性能就会受到影响。 新的调度器解决上述问题的方法是,基于每个 CPU 来分布时间片,并且取消了全局同步和重算循环。调度器使用了两个优先级数组,即活动数组和过期数组,可以通过指针来访问它们。活动数组中包含了所有映射到某个CPU而且时间片尚未用尽的任务。过期数组中包含了一个时间片已经用尽的所有任务的有序列表。如果所有活动任务的时间片都已用尽,那么指向这两个数组的指针互换,过期数组(包含了准备运行的任务)成为活动数组,而空的活动数组成为包含过期任务的新数组。数组的索引存储在一个64位的位图中,找到最高优先级的任务是很容易的。 新的调度器现在不再有大的 runqueue_lock。它维持每个处理器的运行队列/锁机制,以使得两个不同处理器上的两个进程可以完全并行地休眠、唤醒和上下文切换。重算循环(为进程重新计算时间片)和 goodness 循环已经被取消,O(1)算法用于 wakeup() 和 schedulee()。 新调度器的主要好处包括:
内核抢占 2.5的内核抢占模块的工作由 Robert Love 完成。在先前的内核版本中(包括2.4内核),不允许抢占以内核模式运行的任务(包括通过系统调用进入内核模式的用户任务),直到它们自己主动释放 CPU。 在内核2.6中,内核是可抢占的。一个内核任务可以被抢占,为的是让重要的用户应用程序可以继续运行。这样做最主要的优势在于,可以极大地增强系统的用户交互性,用户将会觉得鼠标点击和击键的事件得到了更快速的响应。 当然,不是所有的内核代码段都可以被抢占。可以锁定内核代码的关键部分,不允许抢占。锁定可以确保每个 CPU 的数据结构和状态始终受到保护而不被抢占。 以下的代码片断显示了每个 CPU 的数据结构问题(在SMP系统中):
在这种情形下,如果在特定点发生了内核抢占,任务将会由于重新调度而被分配到其他处理器——smp_processor_id() 将返回一个不同的值。 这种情形应该通过锁定来进行保护。 FPU 模式是另外一种CPU应该被保护起来不被抢占的情形。当内核在执行浮点指令时,FPU 状态不被保存。如果这时发生了抢占,由于重新调度,FPU 状态就会与抢占前完全不同。所以 FPU 代码必须始终被锁定,以防止内核抢占。 锁定可以这样来实现,在关键部分禁止抢占,在之后再激活抢占。以下是在2.6内核中禁止和激活抢占的定义:
使用这些定义,清单 1可以重写成这样: 清单 2. 使用防抢占锁的代码
注意 preempt_disable()/enable()调用是可以嵌套的。也就是说,preempt_disable() 可以被调用 n 次,只有当第 n 次 preempt_enable() 被调用后,抢占才被重新激活。 当使用自旋锁时,抢占是被隐式地禁止的。例如,一个 spin_lock_irqsave() 调用会隐式地通过调用 preempt_disable() 来防止抢占;spin_unlock_irqrestroe() 通过调用 preempt_enable() 来重新激活抢占。 改进的线程模型以及对 NPTL 的支持
线程操作可以提高速度;2.6内核现在可以处理任意数目的线程,PID最大可以到20亿(IA32上)。 另外一个变化是引入了 TLS(Thread Local Storage)系统调用,这个调用允许分配一个或多个 GDT(Global Descriptor Table)条目,作为线程注册表。每个 CPU 有一个 GDT,每个条目对应一个线程。这样就可以实现一个不受创建的线程数限制的1:1线程模型(因为每一个新的内核线程都是为一个用户线程而创建)。2.4内核中每个处理器最多只能支持8,192个线程。 系统调用 clone 被扩展,以优化线程的创建。如果 CLONE_PARENT_SETID 标志被设置,内核会把线程ID存储在一个给定的内存位置,如果当线程结束时 CLONE_CLEARID 标志被设置,内核就会把那个内存位置清空。这有助于用户级的内存管理去识别没有使用的内存块。同样,对线程注册表的信号安全加载的支持也已经融入到这个体系中。当 pthread_join 发生时由内核根据线程ID来完成 Futex(fast user space mutex)。(要了解futex的更多信息,请参阅参考资料). POSIX信号处理在内核空间中完成。一个信号会传递给进程中一个可用的线程;销毁信号会终止整个进程。停止和继续信号也会影响整个进程,这样就可以实现对多线程进程的工作控制。 引入了退出系统调用的一个变种,叫做 exit_group(),这个系统调用终止整个进程和它的线程。此外,退出处理通过引入O(1)算法得到了改进,从而可以在两秒内终止一个具有成千上万个线程的进程(而在2.4内核中完成同样的事情需要15分钟)。 修改了 proc 文件系统,不再报告所有的线程而只是报告原始的线程。这样就避免了 /proc 报告速度的下降。内核保证原始的线程在所有其他线程终止之前不会终止。 虚拟内存的变化 为了理解反向映射技术,让我们来首先简单了解 Linux 虚拟内存系统的一些基本原理。 Linux 内核工作于虚拟内存模式:每一个虚拟页对应一个相应的系统内存的物理页。虚拟页和物理页之间的地址转换由硬件的页表来完成。对于一个特定的虚拟页,根据一条页表记录可以找到对应的物理页,或者是页无法找到的提示(说明存在一个页错误)。但是这种"虚拟到物理"的页映射不是总是一一对应的:多个虚拟页(被不同的进程共享的页)有可能指向同一个物理页。在这种情况下,每个共享进程的页记录将有指向对应物理页的映射。如果有类似这样的情况,当内核想要释放特定的物理页时,事情会变得复杂,因为它必须遍历所有的进程页表记录来查找指向这个物理页的引用;它只能在引用数达到0时才能释放这个物理页,因为它没有别的办法可以知道是不是还存在实际指向这个页的引用。这样当负载较高时会让虚拟内存变得非常慢。 反向地址映射补丁通过在结构页引入一个叫做 pte_chain 的数据结构(物理页结构)来解决这一问题。pte_chain 是一个指向页的 PTE 的简单链接列表,可以返回特定的被引用页的 PTE 列表。页释放一下子变得非常简单了。 不过,在这种模式中存在一个指针开销。系统中的每一个结构页都必须有一个额外的用于 pte_chain 的结构。在一个256M内存的系统中,有64K个物理页,这样就需要有 64KB * (sizeof(struct pte_chain)) 的内存被分配用于 pte_chain 的结构――一个很可观的数字。 有一些可以解决这个问题的技术,包括从结构页中删掉 wait_queue_head_t 域(用于对页的独占访问)。因为这个等待队列极少用到,所以在 rmap 补丁中实现了一个更小的队列,通过哈希队列来找到正确的等待队列。 尽管如此,rmap 的性能――尤其是处于高负载的高端系统――相对于2.4内核的虚拟内存系统还是有了显著的提高。 Linux 2.6的驱动程序移植 首先,相对于2.4来说,改进了内核编译系统,从而获得更快的编译速度。加入了改进的图形化工具:make xconfig(需要Qt库)和make gconfig(需要GTK库)。 以下是2.6编译系统的一些亮点:
内核模块加载器也在2.5中完全被重新实现,这意味着模块编译机制相对于2.4有了很大不同。需要一组新的模块工具来完成模块的加载和缷载 (他们的下载链接可以在参考资料中找到),原来的2.4所用的 makefile 在2.6下不能再用。 新的内核模块加载器是由 Rusty Russel 开发的。它使用内核编译机制,产生一个 .ko(内核目标文件,kernel object)模块目标文件而不是一个 .o 模块目标文件。内核编译系统首先编译这些模块,并将其连接成为 vermagic.o。这一过程在目标模块创建了一个特定部分,以记录使用的编译器版本号,内核版本号,是否使用内核抢占等信息。 现在让我们来看一个例子,分析一下新的内核编译系统如何来编译并加载一个简单的模块。这个模块是一个“hello world”模块,代码和2.4模块代码基本类似,只是 module_init 和 module_exit 要换成 init_module 和 cleanup_module (内核2.4.10模块已经使用这种机制)。这个模块命名为 hello.c,Makefile 文件如下: 清单 3. 驱动程序 makefile 文件示例
makefile 文件使用内核编译机制来编译模块。编译好的模块将被命名为 module.ko,并通过编译 hello.c 和连接 vermagic 而获得。KERNEL_SRC 指定内核源文件所在的目录,SUBDIR 指定放置模块的目录。EXTRA_FLAGS 指定了需要给出的编译期标记。 一旦新模块(module.ko)被创建,它可以被新的模块工具加载或缷载。2.4中的原有模块工具不能用来加载或缷载2.6的内核模块。这个新的模块加载工具会尽量减少在一个设备仍在使用的情况下相应的模块却被缷载的冲突发生,而是在确认这些模块已经没有任何设备在使用后再缷载它。产生这种冲突的原因之一是模块使用计数是由模块代码自己来控制的(通过MOD_DEC/INC_USE_COUNT)。 在2.6中,模块不再需要对引用计数进行加或减,这些工作将在模块代码外部进行。任何要引用模块的代码都必须调用 try_module_get(&module),只有在调用成功以后才能访问那个模块;如果被调用的模块已经被缷载,那么这次调用会失败。相应的,可以通过使用 module_put() 来释放对模块的引用。 内存管理的变化 mempool_t *mempool_create(int min_nr, mempool_alloc_t *alloc_fn, 在这里 min_nr 是需要预分配对象的数目,alloc_fn 和 free_fn 是指向内存池机制提供的标准对象分配和回收例程的指针。他们的类型是: typedef void *(mempool_alloc_t)(int gfp_mask, void *pool_data); pool_data 是分配和回收函数用到的指针,gfp_mask 是分配标记。只有当 __GFP_WAIT 标记被指定时,分配函数才会休眠。 在池中分配和回收对象是由以下程序完成的: void *mempool_alloc(mempool_t *pool, int gfp_mask); mempool_alloc() 用来分配对象;如果内存池分配器无法提供内存,那么就可以用预分配的池。 系统使用 mempool_destroy() 来回收内存池。 除了为内存分配引入了内存池之外,2.5内核还引入了三个用于常规内存分配的新的GFP标记,它们是:
除了内存分配的变化以外,remap_page_range()调用——用来映射页到用户空间——也经过了少量修改。相对于2.4来说,现在它多了一个参数。虚拟内存区域(VMA)指针要作为第一个参数,然后是四个常用的参数(start,end,size 和 protection 标记)。 工作队列接口 struct workqueue_struct *create_workqueue(const char *name); 在这里 name 是工作队列的名字。 工作队列任务可以在编译时或者运行时创建。任务需要封装为一个叫做 work_struct 的结构体。在编译期初始化一个工作队列任务时要用到: DECLARE_WORK(name, void (*function)(void *), void *data); 在这里 name 是 work_struct 的名字,function 是当任务被调度时调用的函数,data 是指向那个函数的指针。 在运行期初始化一个工作队列时要用到: INIT_WORK(struct work_struct *work, void (*function)(void *), void *data); 用下面的函数调用来把一个作业(一个类型为work_struct 结构的工作队列作业/任务)加入到工作队列中: int queue_work(struct workqueue_struct *queue, struct work_struct *work); 在queue_delay_work()中指定 delay,是为了保证至少在经过一段给定的最小延迟时间以后,工作队列中的任务才可以真正执行。 工作队列中的任务由相关的工作线程执行,可能是在一个无法预期的时间(取决于负载,中断等等),或者是在一段延迟以后。任何一个在工作队列中等待了无限长的时间也没有运行的任务可以用下面的方法取消: int cancel_delayed_work(struct work_struct *work); 如果当一个取消操作的调用返回时,任务正在执行中,那么这个任务将继续执行下去,但不会再加入到队列中。清空工作队列中的所有任务使用: void flush_workqueue(struct workqueue_struct *queue); 销毁工作队列使用: void destroy_workqueue(struct workqueue_struct *queue); 不是所有的驱动程序都必须有自己的工作队列。驱动程序可以使用内核提供的缺省工作队列。由于这个工作队列由很多驱动程序共享,任务可能会需要比较长一段时间才能开始执行。为了解决这一问题,工作函数中的延迟应该保持最小或者干脆不要。 需要特别注意的是缺省队列对所有驱动程序来说都是可用的,但是只有经过GP许可的驱动程序可以用自定义的工作队列:
当模块被缷载时应该去调用一个 flash_scheduled_work() 函数,这个函数会使等待队列中所有的任务都被执行。 中断例程的变化 现在的中断处理函数的返回代码是一个 irqreturn_t 类型。这个由 Linus 引入的变化意味着中断处理程序告诉通用的 IRQ 层是否真的要中断。这样做是为了当中断请求不断到来时(原因是驱动程序偶然激活了一个中断位或者硬件坏掉了),捕获假中断(尤其是在共享的PCI线上),而任何驱动程序对此都是无能为力的。在2.6中,驱动程序如果要从一个设备上发出一个中断需要返回 IRQ_HANDLED,如果不是的话返回 IRQ_NONE。这样可以帮助内核的 IRQ 层清楚地识别出哪个驱动程序正在处理那个特定的中断。如果一个中断请求不断到来而且没有注册那个设备的处理程序(例如,所有的驱动程序都返回 IRQ_NONE),内核就会忽略来自那个设备的中断。缺省情况下,驱动程序 IRQ 例程应该返回 IRQ_HANDLED,当驱动程序正在处理那个中断时却返回了 IRQ_NONE,说明存在 bug。新的中断处理程序可能是类似于这样:
注意,cli(),sti(),save_flags()和 restor_flags() 是不赞成使用的方法。取而代之的是 local_save_flags() 和 local_irq_disable(),用来禁止所有的本地中断(本处理器内的)。禁止所有处理器的中断是不可能的。 统一的设备模型
在2.5内核中,与设备驱动程序相关的其他发展包括:
结束语 Linus 已经邀请世界各地的测试人员来查找 bug 和报告问题,并要求发行者提供2.6版本的下载。如果您想参加,您可以在下面的参考资料中找到下载和安装的链接。
| ![]() |
英文原文