Linux(内核剖析):25---中断下半部之(tasklet机制(struct tasklet_struct)、BH机制)

一、tasklet概述

  • tasklet是利用软中断实现的一种下半部机制。我们之前提到过,它和进程没有任何关系。tasklet和软中断在本质上很相似,行为表现也相近,但是,它的接口更简单,锁保护也要求较低
  • 选择到底是用软中断还tasklet其实很简单:通常你应该用tasklet。就像我们在前面看到的,软中断的使用者屈指可数。它只在那些执行频率很高和连续性要求很高的情况下才需要使用而tasklet却有更广泛的用途。大多数情况下用tasklet效果都不错,而且它们还非常容易使用

二、tasklet的实现

  • 因为tasklet是通过软中断实现的,所以它们本身也是软中断
  • 前面讨论过了,tasklet由两类软中断代表:HI_SOFTIRQ和TASKLET_SOFTIRQ。这两者之间唯一的实际区别在于,HI_ SOFTIRQ类型的软中断先于TASKLET_SOFTIRQ类型的软中断执行(参阅前一篇文章:https://blog.csdn.net/qq_41453285/article/details/103996960

①tasklet结构体(struct tasklet_struct)

  • tasklet由tasklet_struct结构表示。每个结构体单独代表一个tasklet,它在<linux/interrupt.h>中定义为:
    • func:是tasklet的处理程序(像软中断中的action一样)
    • data:是func函数的唯一参数
    • state:只能在0、TASKLET_STATE_SCHED、TASKLET_STATE_RUN之间取值
      • TASKLET_STATE_SCHED:表明tasklet已被调度,正准备投入运行
      • TASKLET_STATE_RUN:表明该tasklet智能在多处理器的系统上才会作为一种优化来使用,单处理器系统任何时候都清楚单个tasklet是不是正在运行(它要么就是当前正在执行的代码,要么不是)
    • count:是tasklet的引用计数器。如果count不为0,则tasklet被禁止,不允许执行;如果count为0,tasklet才被激活,并且在被设置为挂起状态时,该tasklet才能够执行

②调度tasklet(tasklet_schedule()、tasklet_hi_schedule()、tasklet_action()、tasklet_hi_action())

  • 已调度的tasklet(等同于被触发的软中断) 存放在两个单处理器数据结构:
    • tasklet_vec(普通tasklet)
    • tasklet_hi_vec(高优先级的tasklet)
    • 这两个数据结构都是由tasklet_struct结构体构成的链表。链表中的每个tasklet_struct代表一个不同的tasklet
  • tasklet由tasklet_schedule()和tasklet_hi_schedule()函数进行调度,它们接受一个指向tasklet_ struct结构的指针作为参数。两个函数非常类似(区别在于一个使用TASKLET_SOFTIRQ而另一 个用HI_SOFTIRQ)。在接下来的内容中我们将仔细研究怎么编写和使用tasklets。现在,让我们先来考察一下tasklet_schedule()的细节:
  • tasklet_schedule()的执行步骤:
    • 1.检查tasklet的状态是否为TASKLET_STATE_SCHED。如果是,说明tasklet已经被调度过了,该函数立即返回
    • 2.调用_tasklety_schedule()
    • 3.保存中断状态,然后禁止本地中断。在我们执行tasklet代码时,这么做能够保证党tasklet_schedule()处理这些tasklet时,处理器上的数据不会弄乱
    • 4.把需要调度的tasklet加到每个处理器一个的tasklet_vec链表或tasklet_hi_vec链表的表头上去
    • 5.唤起TASKLET_SOFTIRQ或HI_SOFTIRQ软中断,这样在下一次调用do_softirq()时就会执行该tasklet
    • 6.恢复中断到原状态并返回
  • 在前面的内容中我们曾经提到过挂起,do_softirq()会尽可能早地在下一个合适的时机执行。 由于大部分tasklet和软中断都是在中断处理程序中被设置成待处理状态,所以最近一个中断返回的时候看起来就是执行do_softirq()的最佳时机。因为TASKLET_SOFTIRQ和HI_SOFTIRQ已经被触发了,所以do_softirq()会执行相应的软中断处理程序。而这两个处理程序,tasklet_ action()和tasklet_hi_action(),就是tasklet处理的核心。让我们观察它们做了什么:
    • 1.禁止中断(没有必要首先保存其状态,因为这里的代码总是作为软中断被调用,而且中断总是被激活的),并为当前处理器检索tasklet_vec或tasklet_hig_vec链表
    • 2.将当前处理器上的该链表设置为NULL,达到清空的效果
    • 3.允许应中断。没有必要再恢复它们回原状态,因为这段程序本身就是作为软中断处理程序被调用的,所以中断是应该被允许的
    • 4.循环遍历获得链表上的每一个待处理的tasklet
    • 5.如果是多处理器系统,通过检査TASKLET_STATE_RUN来判断这个tasklet是否正在其他处理器上运行。如果它正在运行,那么现在就不要执行,跳到下一个待处理的tasklet去(回忆一下,同一时间里,相同类型的tasklet只能有一个执行)
    • 6.如果当这个tasklet没有执行,将其状态设置为TASKLET_STATE_RUN,这样別的处理器就不会再去执行它了
    • 7.检查count值是否为0,确保tasklet没有被禁止。如果tasklet被禁止了,则跳到下一个挂起的tasklet去
    • 8.我们已经清楚地知道这个tasklet没有在其他地方执行,并且被我们设置成执行状态,这样它在丼他部分就不会被执行,并且引用计数为0,现在可以执行tasklet的处理程序了
    • 9.tasklet运行完毕蛮清楚tasklet的state域的TASKLET_STATE_RUN状态标志
    • 10.重复执行下一个tasklet,直至没有剩余的等待处理的tasklet
  • tasklet的实现很简单,但非常巧妙。我们可以看到,所有的tasklet都通过重复运用H I_ SOFTIRQ和TASKLET_SOFTIRQ这两个软中断实现。当一个tasklet被调度时,内核就会唤起 这两个软中断中的一个。随后,该软中断会被特定的函数处理,执行所有已调度的tasklet。这个函数保证同一时间里只有一个给定类别的tasklet会被执行(但其他不同类型的tasklet可以同时执行)。所有这些复杂性都被一个简洁的接口隐藏起来了

三、使用tasklet

  • 大多数情况下,为了控制一个寻常的硬件设备,tasklet机制都是实现自己的下半部的最佳选 择。tasklet可以动态创建,使用方便,执行起来也还算快。此外,尽管它们的名字使人混淆,但 能加深你的印象:那是逗人喜爱的

①声明自己的tasklet(DECLARE_TASKLET、DECLARE_TASKLET_DISABLED、tasklet_init)

  • 你既可以静态地创建tasklet,也可以动态地创建它。选择哪种方式取决于你到底是有(或者时想要)一个对tasklet的直接引用还是间接引用
  • 如果你准备静态地创建一个tasklet(也就是有一个它的直接引用),使用下<linux/interrupt.h>中定义的两个宏中的一个:
    • 这两个宏都能根据给定的名称静态地创建一个task_struct结构
    • 当该tasklet被调度以后给定的函数func会被执行,它的参数由data给出
    • 这两个宏之间的区别在于引用计数器的初始值设置不同。面一个宏把创建的tasklet的引用计数器设置为0,该tasklet处于激活状态。另一 个把引用计数器设置为1,所以该tasklet处于禁止状态

  • 下面是一个例子:

  • 还可以通过将一个间接引用(一个指针)赋给一个动态创建的tasklet_struct结构的方式来初始化一个tasklet_init():

②编写自己的tasklet处理程序(tasklet_handler)

  • tasklet处理程序必须符合规定的函数类型:

  • 为是靠软中断实现,所以tasklet不能睡眠。这意味着你不能在tasklet中使用信号量或者其他什么阻塞式的函数。由于tasklet运行时允许相应中断,所以你必须做好预防工作(如屏蔽中断然后获取一个锁),如果你的tasklet和中断处理程序之间共享了某些数据的话。两个相同的tasklet决不会同时执行,这点和软中断不同——尽管两个不同的tasklet可以在两个处理器上同时执行。如果你的tasklet和其他的tasklet或者是软中断共享了数据,你必须进行适当地锁保护

③调度自己的tasklet(tasklet_schedule)

  • 通过调用tasklet_schedule()函数并穿肚给它相应的tasklt_struct的指针,该tasklet就会被调度以便执行:

  • 在tasklet被调度以后,只要有机会它就会尽可能早地运行。在它还没有得到运行机会之前, 如果有一个相同的tasklet又被调度了,那么它仍然只会运行一次。而如果这时它已经开始运行了,比如说在另外一个处理器上,那么这个新的tasklet会被重新调度并再次运行。作为一种优化措施,一个tasklet总在调度它的处理器上执行——这是希望能更好地利用处理器的高速缓存

④禁止/激活/消除tasklet

  • 你可以调用tasklet_disable()函数来禁止某个指定的tasklet。如果该tasklet当前正在执行,这个函数会等到它执行完毕再返回
  • 你也可以调用tasklet_disable_nsync()函数,它也用来禁止指定的tasklet,不过它无须在返回前等待tasklet执行完毕。这么做往往不太安全,因为你无法估计该tasklet是否仍在执行
  • 调用tasklet_enable()函数可以激活一个tasklet,如果希望激活DECLARE_TASKLET_DISABLED()创建的tasklet,你也得调用这个函数,如:

  • 你可以通过调用tasklet_kill()函数从挂起的队列中去掉一个tasklet。该函数的参数是一个指向某个tasklet的tasklet_struct的长指针 在处理一个经常重新调度它自身的tasklet的时候,从 挂起的队列中移去已调度的tasklet会很有用。这个函数首先等待该tasklet执行完毕,然后再将 它移去。当然,没有什么可以阻止其他地方的代码重新调度该tasklet。由于该函数可能会引起休眠 ,所以禁止在中断上下文中使用它

四、ksoftirqd内核线程

  • 每个处理器都有一组辅助处理软中断(和tasklet)的内核线程。当内核中出现大量软中断的时候,这些内核进程就会辅助处理它们。因为tasklet通过用软件中断实施,下面的讨论同样适用于软中断和tasklet。简洁起见,我们将主要参考软中断
  • 我们前面曾经阐述过,对于软中断,内核会选择在几个特殊时机进行处理。而在中断处理 程序返回时处理是最常见的。软中断被触发的频率有时可能很高(像在进行大流量的网络通信期间)。更不利的是,处理函数有时还会自行重复触发。也就是说,当一个软中断执行的时候,它 可以重新触发自己以便再次得到执行(事实上,网络子系统就会这么做)。如果软中断本身出现的频率就高,再加上它们又有将自己重新设置为可执行状态的能力,那么就会导致用户空间进程无法获得足够的处理器时间,因而处于饥饿状态。而且,单纯的对重新触发的软中断采取不立即处理的策略,也无法让人接受。当软中断最初提出时,就是一个让人进退维谷的问題,亟待解 决,而直观的解决方案又都不理想。首先,就让我们看看两种最容易想到的直观的方案
  • 第一种方案是,只要还有被触发并等待处理的软中断,本次执行就要负责处理,重新触发的软中断也在本次执行返回前被处理。这样做可以保证对内核的软中断采取即时处理的方式,关键 在于,对重新触发的软中断也会立即处理。当负载很高的时候这样做就会出问题,此时会有大最被触发的软中断,而它们本身又会重复触发。系统可能会一直处理软中断,根本不能完成其他任 务。用户空间的任务被忽略了——实际上,只有软中断和中断处理程序轮流执行,而系统的用户 只能等待。只有在系统永远处于低负载的情况下,这种方案才会有理想的运行效果;只要系统有 哪怕是中等程度的负载量,这种方案就无法让人满意。用户空间根本不能容忍有明显的停顿 现
  • 第二种方案选择不处理重新触发的软中断。在从中断返回的时候,内核和平常一样,也会检查所有挂起的软中断并处理它们。但是,任何自行重新触发的软中断都不会马上处理,它们被放到下一个软中断执行时去处理。而这个时机通常也就是下一次中断返回的时候,这等于是说,一定得等一段时间,新的(或者重新触发的)软中断才能被执行。可是,在比较空闲的系统中,立 即处理软中断才是比较好的做法。很不幸,这个方案显然又是一个时好时坏的选择。尽管它能保证用户空间不处于饥饿状态,但它却让软中断忍受饥饿的痛苦,而根本没有好好利用闲置的系统资源
  • 在设计软中断时,开发者就意识到需要一些折中。最终在内核中实现的方案是不会立即处理 重新触发的软中断。而作为改进,当大量软中断出现的时候,内核会唤醒一组内核线程来处理这些负载。这些线程在最低的优先级上运行(nice值是19),这能避免它们跟其他重要的任务抢夺资源。但它们最终肯定会被执行,所以,这个折中方案能够保证在软中断负担很重的时候,用户程序不会因为得不到处理时间而处于饥饿状态。相应的,也能保证“过量”的软中断终究会得到处理。最后,在空闲系统上,这个方案同样表现良好,软中断处理得非常迅速(因为仅存的内核线程肯定会马上调度)
  • 每个处理器都有一个这样的线程。所有线程的名字都叫做ksoftirqd/n,区别在于n,它对应的是处理器的编号。在一个双CPU的机器上就有两个这样的线程,分别叫ksoftirqd/0和ksoftirqd/1。为了保证只要有空闲的处理器,它们就会处理软中断,所以给每个处理器都分配一个这样的线程。一旦该线程被初始化,它就会执行类似下面这样的死循环:

  • 只要有待处理的软中断(由softirq_pending()函数负责实现),ksoftirq就会调用do_softirq()去处理它们。通过重复执行这样的操作,重新触发的软中断也会被执行。如果有必要的话,每次迭代后都会调用schedule()以便让更重要的进程得到处理机会。当所有需要执行的操作都完成以后,该内核线程将自己设置为TASK_INTERRUPTIBLE状态,唤起调度程序选择其他可执行进程投入运行
  • 只要do_softirq()函数发现已经执行过的内核线程重新触发了它自己,软中断内核线程就会被唤醒

五、老的BH机制

  • 尽管BH机制令人欣慰地退出了历史舞台,在2.6版内核中已经难觅踪迹了。可是,它毕竟曾经历经了漫长的时光——从最早版本的内核就开始了。由于其余威尚存,所以仅仅不经意地提起它是不够的,尽管在2.6版本中已经不再使用它了,但历史就是历史,应该被了解
  • BH很古老,但它能揭示一些东西。所有BH都是静态定义的,最多可以有32个。由于处理函数必须在编译时就被定义好,所以实现模块时不能直接使用BH接口。不过业已存在的BH倒是可以利用。随着时间的推移,这种静态要求和最大为32个的数目限制最终妨碍了它们的应用
  • 每个BH处理程序都严格地按顺序执行——不允许任何两个BH处理程序同时执行,即使它 们的类型不同。这样做倒是使同步变得简单了,可是却不利于多处理器的可扩展性,也不利于大型SMP的性能。使用BH的驱动程序很难从多个处理器上受益,特别是网络层,可以说为此饱受困扰
  • 除了这些特点,BH机制和 tasklet就很像了。实际上,在 2.4内核中,BH就是基于tasklet实现的。所有可能的32个BH都通过<Linux/interrupt.h>中定义的常量表示。如果需要将一个BH标志为挂起状态,可以把相应的BH号传给mark_bh()函数。在2.4内核中,这将导致随后调BH tasklet,具体工作是由函数bh_action()完成的。而在2.4内核以前,BH机制独立实现,不依赖任何低级BH机制,这 现在的软中断很像
  • 由于这种形式的下半部机制存在缺点,内核开发者们希望引入任务队列机制来代替它。尽管任务队列得到了不少使用者的认可,但它实际上并没有达成这个目的。在2.3版的内核中,引入新的软中断和tasklet机制也就结束了对BH的使用。BH机制基于tasklet重新实现。不幸的是,为新接口本身降低了对执行的序列化保障,所以从BH接口移植到tasklet或软中断接口上操作起来非常复杂。在2.5版中,这种移植最终在定时器和SCSI(最后的BH使用)转换到软中断机制后完成了。于是内核开发者们立即除去了BH接口。终于解脱了,BH
发布了1342 篇原创文章 · 获赞 883 · 访问量 24万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 游动-白 设计师: 上身试试

分享到微信朋友圈

×

扫一扫,手机浏览