API，第2部分可延迟函数、内核微线程以及工作.doc

API，第 2 部分 可延迟函数、内核微线程以及工作 ? Linux 2.6 bottom halves简介 简介：对于高频率线程操作，Linux内核提供微线程和工作队列。微线程和工作队列执行可延迟功能并替代驱动程序当中原有的bottom-half机制。本文研究如何在内核中使用微线程和工作队列，并展示如何利用这些APIs来构建可延迟函数。 发布日期：2010年4月11日 其他语言版本：英文 联系Tim Tim是我们最受欢迎、作品最多的作者之一。查看并与他以及My developerWorks中的其他作者和相关读者取得联系。更多内容请参考Tim专栏。本文研究多个用于在内核环境当中延迟处理的方法(特别是在Linux内核版本2.6.27.14当中)。尽管这些方法针对Linux内核，但方法背后的理念，对于系统架构研究具有更广泛的意义。例如，可以将这些理念应用到传统的嵌入式系统当中，取代原有的调度程序来进行任务调度。 在开始研究用于内核中的可延迟函数之前，让我们先了解一下相关问题的背景情况。操作系统会因为一个硬件事件而产生中断(例如出现了一个来自网卡的数据包)，对该事件的处理过程从一个中断开始。通常，中断会导致大量任务停止。其中一些任务是在中断上下文完成的，然后任务被传递给软件栈来继续处理(参见图1)。 问题在于，有多少任务需要在中断上下文完成?关于中断上下文的问题是，在此期间部分或者全部中断可以被禁止，这就增加了处理其他硬件问题的时延(并导致处理习惯的改变)。因此，有必要简化中断过程中要完成的任务，把一些任务转移到内核上下文中去完成(在该上下文，处理器资源更有可能被高效共享)。 正如图1所示,在中断上下文所完成的处理过程称为top half，基于中断并被推出中断上下文之外的处理过程称为bottom half(top half要依据bottom half来安排后续的处理过程)。bottom-half处理过程在内核上下文完成，这意味着允许中断操作。因此通过延迟时间不敏感的任务，来更迅速处理高频率中断事件，能够带来性能的优化。 Linux内核版本 这里对微线程及工作队列的讨论采用了2.6.27.14版本的Linux内核。Linux能够快速响应各种功能需求，延迟功能也不例外。自Linux2.3版本内核开始，就提供了软中断功能，具有一组32个静态定义的bottom halves。作为静态元素，其定义在编译过程中完成(不同于新的动态机制)。软中断用于在内核线程上下文中处理时间要求严格的处理过程(软件中断)。可以在./kernel/softirq.c中找到软中断的来源。在2.3版本的Linux内核中还引入了微线程(参见./include/linux/interrupt.h)。微线程的构建基于软中断，用于允许动态生成可延迟函数。最终，在2.5版本Linux内核中引入了工作队列(参见./include/linux/workqueue.h)。工作队列允许将任务延迟到中断上下文之外，进入内核处理上下文。 现在我们探讨一下任务延迟、微线程以及工作队列的动态机制。 软中断最初为具有32个软中断条目的矢量，用来支持一系列的软件中断特性。当前，只有9个矢量被用于软中断，其中之一是TASKLET_SOFTIRQ(参见./include/linux/interrupt.h)。虽然软中断还存在于内核中，推荐采用微线程和工作队列，而不是分配新的软中断矢量。 微线程是一个延迟方法，可以实现将已登记的函数进行推后运行。top half(中断处理程序)完成少量的任务，然后安排微线程在晚些的bottom half中执行。 /*Declare aTasklet(the Bottom-Half)*/void tasklet_function(unsigned long data)；DECLARE_TASKLET(tasklet_example,tasklet_function,tasklet_data)；./*Schedule the Bottom-Half*/tasklet_schedule(tasklet_example)； 一个给定的微线程只运行在一个CPU中(就是用于调用该微线程的那个CPU)，同一微线程永远不会同时运行在多个CPU中。但是不同的微线程可以同时运行在不同的CPU中。 微线程可由tasklet_struct结构体表示(参见图2)，其中包含了用于管理和维护微线程的必要数据(状态，通过atomic_t来实现允许/禁止控制，函数指针，数据，以及链表引用)。 通过软中断机制来调度微线程，当机器处于严重软件中断负荷之下时，可通过ksoftirqd(一种每CPU内核线程)软中断来调度。下面将探讨微线程应用编程接口(API)中支持的各类函数。 嵌入式系统继承物 微线程和工作队