Linux内核中的软中断tasklet和工作队列具体解释

Posted 2020-10-03 yxysuanfa

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Linux内核中的软中断tasklet和工作队列具体解释相关的知识，希望对你有一定的参考价值。

[TOC]
本文基于Linux2.6.32内核版本号。

引言

软中断、tasklet和工作队列并非Linux内核中一直存在的机制，而是由更早版本号的内核中的“下半部”（bottom half）演变而来。

下半部的机制实际上包含五种，但2.6版本号的内核中。下半部和任务队列的函数都消失了，仅仅剩下了前三者。
介绍这三种下半部实现之前。有必要说一下上半部与下半部的差别。

上半部指的是中断处理程序，下半部则指的是一些尽管与中断有相关性可是能够延后运行的任务。

举个样例：在网络传输中。网卡接收到数据包这个事件不一定须要立即被处理，适合用下半部去实现；可是用户敲击键盘这种事件就必须立即被响应，应该用中断实现。
两者的主要差别在于：中断不能被同样类型的中断打断。而下半部依旧能够被中断打断；中断对于时间很敏感，而下半部基本上都是一些能够延迟的工作。由于二者的这种差别，所以对于一个工作是放在上半部还是放在下半部去运行，能够參考以下4条：

假设一个任务对时间很敏感。将其放在中断处理程序中运行。
假设一个任务和硬件相关，将其放在中断处理程序中运行。
假设一个任务要保证不被其它中断（特别是同样的中断）打断，将其放在中断处理程序中运行。
其它全部任务，考虑放在下半部去运行。
有写内核任务须要延后运行。因此才有的下半部，进而实现了三种实现下半部的方法。这就是本文要讨论的软中断、tasklet和工作队列。

下表能够更直观的看到它们之间的关系。
技术分享

软中断

软中断作为下半部机制的代表，是随着SMP（share memory processor）的出现应运而生的，它也是tasklet实现的基础（tasklet实际上仅仅是在软中断的基础上加入了一定的机制）。软中断通常是“可延迟函数”的总称，有时候也包含了tasklet（请读者在遇到的时候依据上下文判断是否包含tasklet）。它的出现就是由于要满足上面所提出的上半部和下半部的差别，使得对时间不敏感的任务延后运行，而且能够在多个CPU上并行运行。使得总的系统效率能够更高。

它的特性包含：

产生后并非立即能够运行，必须要等待内核的调度才干运行。软中断不能被自己打断(即单个cpu上软中断不能嵌套运行)。仅仅能被硬件中断打断（上半部）。
能够并发运行在多个CPU上（即使同一类型的也能够）。所以软中断必须设计为可重入的函数（同意多个CPU同一时候操作），因此也须要使用自旋锁来保其数据结构。

实现原理和实例

软中断的调度时机:

do_irq完毕I/O中断时调用irq_exit。
系统使用I/O APIC,在处理完本地时钟中断时。
local_bh_enable，即开启本地软中断时。
SMP系统中。cpu处理完被CALL_FUNCTION_VECTOR处理器间中断所触发的函数时。
ksoftirqd/n线程被唤醒时。
以下以从中断处理返回函数irq_exit中调用软中断为例详细说明。

触发和初始化的的流程如图所看到的:

软中断处理流程

asmlinkage void __do_softirq(void)
{
    struct softirq_action *h;
    __u32 pending;
    int max_restart = MAX_SOFTIRQ_RESTART;
    int cpu;

    pending = local_softirq_pending();
    account_system_vtime(current);

    __local_bh_disable((unsigned long)__builtin_return_address(0));
    lockdep_softirq_enter();

    cpu = smp_processor_id();
restart:
    /* Reset the pending bitmask before enabling irqs */
    set_softirq_pending(0);

    local_irq_enable();

    h = softirq_vec;

    do {
        if (pending & 1) {
            int prev_count = preempt_count();
            kstat_incr_softirqs_this_cpu(h - softirq_vec);

            trace_softirq_entry(h, softirq_vec);
            h->action(h);
            trace_softirq_exit(h, softirq_vec);
            if (unlikely(prev_count != preempt_count())) {
                printk(KERN_ERR "huh, entered softirq %td %s %p"
                       "with preempt_count %08x,"
                       " exited with %08x?\n", h - softirq_vec,
                       softirq_to_name[h - softirq_vec],
                       h->action, prev_count, preempt_count());
                preempt_count() = prev_count;
            }

            rcu_bh_qs(cpu);
        }
        h++;
        pending >>= 1;
    } while (pending);

    local_irq_disable();

    pending = local_softirq_pending();
    if (pending && --max_restart)
        goto restart;

    if (pending)
        wakeup_softirqd();

    lockdep_softirq_exit();

    account_system_vtime(current);
    _local_bh_enable();
}

首先调用local_softirq_pending函数取得眼下有哪些位存在软件中断。
调用__local_bh_disable关闭软中断，事实上就是设置正在处理软件中断标记，在同一个CPU上使得不能重入__do_softirq函数。
又一次设置软中断标记为0，set_softirq_pending又一次设置软中断标记为0，这样在之后又一次开启中断之后硬件中断中又能够设置软件中断位。
调用local_irq_enable。开启硬件中断。
之后在一个循环中。遍历pending标志的每一位，假设这一位设置就会调用软件中断的处理函数。在这个过程中硬件中断是开启的，随时能够打断软件中断。这样保证硬件中断不会丢失。
之后关闭硬件中断(local_irq_disable)，查看是否又有软件中断处于pending状态。假设是，而且在本次调用__do_softirq函数过程中没有累计反复进入软件中断处理的次数超过max_restart=10次，就能够又一次调用软件中断处理。假设超过了10次，就调用wakeup_softirqd()唤醒内核的一个进程来处理软件中断。设立10次的限制。也是为了避免影响系统响应时间。
调用_local_bh_enable开启软中断。

软中断内核线程

之前我们分析的触发软件中断的位置事实上是中断上下文中，而在软中断的内核线程中实际已经是进程的上下文。
这里说的软中断上下文指的就是系统为每一个CPU建立的ksoftirqd进程。
软中断的内核进程中主要有两个大循环，外层的循环处理有软件中断就处理。没有软件中断就休眠。内层的循环处理软件中断，每循环一次都试探一次是否过长时间占领了CPU，须要调度就释放CPU给其它进程。详细的操作在凝视中做了解释。

    set_current_state(TASK_INTERRUPTIBLE);
    //外层大循环。
    while (!kthread_should_stop()) {
        preempt_disable();//禁止内核抢占，自己掌握cpu
        if (!local_softirq_pending()) {
            preempt_enable_no_resched();
            //假设没有软中断在pending中就让出cpu
            schedule();
            //调度之后又一次掌握cpu
            preempt_disable();
        }

        __set_current_state(TASK_RUNNING);

        while (local_softirq_pending()) {
            /* Preempt disable stops cpu going offline.
               If already offline, we‘ll be on wrong CPU:
               don‘t process */
            if (cpu_is_offline((long)__bind_cpu))
                goto wait_to_die;
            //有软中断则開始软中断调度
            do_softirq();
            //查看是否须要调度，避免一直占用cpu
            preempt_enable_no_resched();
            cond_resched();
            preempt_disable();
            rcu_sched_qs((long)__bind_cpu);
        }
        preempt_enable();
        set_current_state(TASK_INTERRUPTIBLE);
    }
    __set_current_state(TASK_RUNNING);
    return 0;

wait_to_die:
    preempt_enable();
    /* Wait for kthread_stop */
    set_current_state(TASK_INTERRUPTIBLE);
    while (!kthread_should_stop()) {
        schedule();
        set_current_state(TASK_INTERRUPTIBLE);
    }
    __set_current_state(TASK_RUNNING);
    return 0;

tasklet

由于软中断必须使用可重入函数，这就导致设计上的复杂度变高。作为设备驱动程序的开发人员来说，添加了负担。而假设某种应用并不须要在多个CPU上并行运行，那么软中断事实上是没有必要的。

因此诞生了弥补以上两个要求的tasklet。它具有以下特性：
a）一种特定类型的tasklet仅仅能运行在一个CPU上，不能并行，仅仅能串行运行。
b）多个不同类型的tasklet能够并行在多个CPU上。

c）软中断是静态分配的。在内核编译好之后，就不能改变。但tasklet就灵活很多，能够在运行时改变（比方加入模块时）。

tasklet是在两种软中断类型的基础上实现的。因此假设不须要软中断的并行特性，tasklet就是最好的选择。也就是说tasklet是软中断的一种特殊使用方法。即延迟情况下的串行运行。

实现原理

调度原理

static inline void tasklet_schedule(struct tasklet_struct *t)
{
    if (!test_and_set_bit(TASKLET_STATE_SCHED, &t->state))
        __tasklet_schedule(t);
}
void __tasklet_schedule(struct tasklet_struct *t)
{
    unsigned long flags;

    local_irq_save(flags);
    t->next = NULL;
    *__get_cpu_var(tasklet_vec).tail = t;
    __get_cpu_var(tasklet_vec).tail = &(t->next);//加入低优先级列表
    raise_softirq_irqoff(TASKLET_SOFTIRQ);//触发软中断
    local_irq_restore(flags);
}

tasklet运行过程
TASKLET_SOFTIRQ相应运行函数为tasklet_action。HI_SOFTIRQ为tasklet_hi_action，以tasklet_action为例说明。tasklet_hi_action大同小异。

static void tasklet_action(struct softirq_action *a)
{
    struct tasklet_struct *list;

    local_irq_disable();
    list = __get_cpu_var(tasklet_vec).head;
    __get_cpu_var(tasklet_vec).head = NULL;
    __get_cpu_var(tasklet_vec).tail = &__get_cpu_var(tasklet_vec).head;//取得tasklet链表
    local_irq_enable();

    while (list) {
        struct tasklet_struct *t = list;

        list = list->next;

        if (tasklet_trylock(t)) {
            if (!atomic_read(&t->count)) {
                //运行tasklet
                if (!test_and_clear_bit(TASKLET_STATE_SCHED, &t->state))
                    BUG();
                t->func(t->data);
                tasklet_unlock(t);
                continue;
            }
            tasklet_unlock(t);
        }
        //假设t->count的值不等于0，说明这个tasklet在调度之后。被disable掉了。所以会将tasklet结构体又一次放回到tasklet_vec链表。并又一次调度TASKLET_SOFTIRQ软中断，在之后enable这个tasklet之后又一次再运行它
        local_irq_disable();
        t->next = NULL;
        *__get_cpu_var(tasklet_vec).tail = t;
        __get_cpu_var(tasklet_vec).tail = &(t->next);
        __raise_softirq_irqoff(TASKLET_SOFTIRQ);
        local_irq_enable();
    }
}

技术分享

工作队列

从上面的介绍看以看出，软中断运行在中断上下文中。因此不能堵塞和睡眠。而tasklet使用软中断实现。当然也不能堵塞和睡眠。但假设某延迟处理函数须要睡眠或者堵塞呢？没关系工作队列就能够如您所愿了。
把推后运行的任务叫做工作（work），描写叙述它的数据结构为work_struct ，这些工作以队列结构组织成工作队列（workqueue），其数据结构为workqueue_struct 。而工作线程就是负责运行工作队列中的工作。系统默认的工作者线程为events。
工作队列(work queue)是第二种将工作推后运行的形式。

工作队列能够把工作推后，交由一个内核线程去运行—这个下半部分总是会在进程上下文运行，但由于是内核线程，其不能訪问用户空间。最重要特点的就是工作队列同意又一次调度甚至是睡眠。

通常。在工作队列和软中断/tasklet中作出选择很easy。可使用以下规则：
- 假设推后运行的任务须要睡眠，那么仅仅能选择工作队列。

- 假设推后运行的任务须要延时指定的时间再触发，那么使用工作队列。由于其能够利用timer延时(内核定时器实现)。
- 假设推后运行的任务须要在一个tick之内处理。则使用软中断或tasklet。由于其能够抢占普通进程和内核线程。同一时候不可睡眠。

- 假设推后运行的任务对延迟的时间没有不论什么要求。则使用工作队列，此时通常为无关紧要的任务。
实际上。工作队列的本质就是将工作交给内核线程处理，因此其能够用内核线程替换。

可是内核线程的创建和销毁对编程者的要求较高，而工作队列实现了内核线程的封装，不易出错，所以我们也推荐使用工作队列。

实现原理

工作队列的组织结构
即workqueue_struct、cpu_workqueue_struct与work_struct的关系。
一个工作队列相应一个work_queue_struct。工作队列中每cpu的工作队列由cpu_workqueue_struct表示，而work_struct为其上的详细工作。
关系例如以下图所看到的:

2.工作队列的工作过程
应用实例
linux各个接口的状态(up/down)的消息须要通知netdev_chain上感兴趣的模块同一时候上报用户空间消息。这里使用的就是工作队列。
详细流程图例如以下所看到的：

是否处于中断中在Linux中是通过preempt_count来判断的,详细例如以下：在linux系统的进程数据结构里，有这么一个数据结构:
#define preempt_count() (current_thread_info()->preempt_count)
利用preempt_count能够表示是否处于中断处理或者软件中断处理过程中,例如以下所看到的：
# define hardirq_count() (preempt_count() & HARDIRQ_MASK)
#define softirq_count() (preempt_count() & SOFTIRQ_MASK)
#define irq_count() (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_MASK | NMI_MASK))
#define in_irq() (hardirq_count())
#define in_softirq() (softirq_count())
#define in_interrupt() (irq_count())

preempt_count的8～23位记录中断处理和软件中断处理过程的计数。
假设有计数，表示系统在硬件中断或者软件中断处理过程中。 ?