IO机制vs下半部机制vs并发控制机制教程.pptxVIP

IO机制vs下半部机制vs并发控制机制 Jet.chen Jet.chen.g@ 目录 预备知识 三种机制的比较 下半部机制 并发控制机制汇总 驱动IO机制汇总 FAQ 预备知识 1.三种线程:内核线程、轻量级进程、用户线程 内核线程 ：kthread_create() 轻量级进程： clone() 用户线程：Pthread_create() 2.一种进程:用户进程 linux普通应用：API ：fork/vfork/clone/ Linux中，每个XX都有一个task_struct，所以线程和进程可以使用同一调度器调度。因为Linux中进程的概念已经被抽象成了计算状态加资源的集合，这些资源在进程间可以共享。 为何要区分？使用资源和同步效率，调度开销等都不一样。 知识预备-进程上下文和中断上下文 概念 描述 什么时候发生 进程上下文 主要是异常处理程序和内核线程。内核之所以进入进程上下文是因为进程自身的一些工作需要在内核中做。例如，系统调用是为当前进程服务的，异常通常是处理进程导致的错误状态等。所以在进程上下文中引用current是有意义的。 进程调度； 系统调用； 中断上下文 是因为中断信号而导致的中断处理或软中断。而中断信号的发生是随机的，中断处理程序及软中断并不能事先预测发生中断时当前运行的是哪个进程，所以在中断上下文中引用current是可以的，但没有意义。事实上，对于A进程希望等待的中断信号，可能在B进程执行期间发生。例如，A进程启动写磁盘操作，A进程睡眠后现在时B进程在运行，当磁盘写完后磁盘中断信号打断的是B进程，在中断处理时会唤醒A进程。 发生中断； ? 为什么在中断上下文中不能休眠?原因在于中断上下文不是一个进程上下文，其没有一个 专门用来描述CPU寄存器等信息的数据结构，所以无法被调度器调度。如果将中断上下文 也设计成进程上下文，那么调度器就可以对其进行调度，如果在开中断的情况下， 其自然就可以睡眠了。但是，如果这样设计，那么中断处理的效率将会降低。 中断（硬中断、软中断）处理都是些耗时不是很长，对实时性要求很高，执行频度较高的应用， 所以，如果采用一个专门的后台daemon对其处理，显然并不合适。 三种机制的比较 机制 描述 种类实现 下半部机制 由下到上的 通知机制； 软中断，工作队列，tasklet，内核定时器等； 同步/异步 IO机制 是由上到下（或者驱动程序自发）的 IO通信机制。分为阻塞IO(异步)与非阻塞IO(同步) 等待队列，poll，epoll，Completions 机制等 并发控制机制 提供并发控制机制，对共享资源进行保护。 spinlock，mutex, 信号量，中断屏蔽、顺序锁(seqlock)、RCU(Read-Copy-Update)等 在编程中 往往三者互相使用： ?比如 hwm_sensor的驱动：用到（内核定时器+工作队列+mutex 取决于 项目设计的需要。） Mtk logdump ：就用到poll +等待队列 下半部机制 机制 是否在进程上下文 是否在中断上下文 可否 睡眠 是否需要内核线程 性能 CPU的支持特性 是否需要调度 应用场合 软中断 yes Yes No 可有可无，取决于调用时机 高 1）一个类型的软中断可以执行在多个CPU； 2）并发运行在多个CPU上（即使同一类型的也可以）。所以软中断必须设计为可重入的函数（允许多个CPU同时操作），因此也需要使用自旋锁来保护其数据结构。 YES 考虑因素： 多CPU; 不可睡眠，不可阻塞； 软中断是在编译期间静态分配； 系统开销相对小； 设计难度高； 适合执行频率高和连续性执行要求高的情况， 性能较高； 应用： 目前只有两个子系直接使用软中断：网络和SCSI。 例如在网络子系统中，注册了如下两个softirq及其处理函数： open_softirq(NET_TX_SOFTIRQ, net_tx_action);--注册softirq open_softirq(NET_RX_SOFTIRQ, net_rx_action);--触发softirq ? tasklet yes YES NO 可有可无，取决于调用时机 中 1）一个类型的tasklet只能执行在单个CPU； 不能并行，只能串行执行。 2）多个不同类型的tasklet可以并行在多个CPU上。 ? YES 考虑因素： 单CPU； 不可睡眠，不可阻塞; 动态分配； 系统开销相对小； 设计难度小； 适合执行频率低，连续性要求低的情况下； 性能中； 应用： TP,键盘，鼠标。大部分设备驱动都使用它。 下半部机制 工作队列 YES NO YES YES 低 1）每个工作队列(仅限于MT)都