Linux 中断子系统之softirq

Myth丶恋晨 2023-01-07 03:54 217阅读 0赞

# Linux 中断子系统之softirq #

## 1 前言 ##

对于中断处理而言，linux将其分成了两个部分，一个叫做中断handler（top half），是全程关闭中断的，另外一部分是deferable task（bottom half），属于不那么紧急需要处理的事情。在执行bottom half的时候，是开中断的。有多种bottom half的机制，例如：softirq、tasklet、workqueue或是直接创建一个kernel thread来执行bottom half（这在旧的kernel驱动中常见，现在，一个理智的driver厂商是不会这么做的）。本文主要讨论softirq机制。由于tasklet是基于softirq的，因此本文也会提及tasklet，但主要是从需求层面考虑，不会涉及其具体的代码实现。

在普通的驱动中一般是不会用到softirq，但是由于驱动经常使用的tasklet是基于softirq的，因此，了解softirq机制有助于撰写更优雅的driver。softirq不能动态分配，都是静态定义的。内核已经定义了若干种softirq number，例如网络数据的收发、block设备的数据访问（数据量大，通信带宽高），timer的deferable task（时间方面要求高）。

## 2 Softirq机制 ##

### 2.1 Softirq number ###

enum
    { 
    	HI_SOFTIRQ=0,
    	TIMER_SOFTIRQ,
    	NET_TX_SOFTIRQ,
    	NET_RX_SOFTIRQ,
    	BLOCK_SOFTIRQ,
    	IRQ_POLL_SOFTIRQ,
    	TASKLET_SOFTIRQ,
    	SCHED_SOFTIRQ,
    	HRTIMER_SOFTIRQ, /* Unused, but kept as tools rely on the numbering. Sigh! */
    	RCU_SOFTIRQ,    /* Preferable RCU should always be the last softirq */
    
    	NR_SOFTIRQS
    };

HI\_SOFTIRQ用于高优先级的tasklet；  
TASKLET\_SOFTIRQ用于普通的tasklet。TIMER\_SOFTIRQ是for software timer的（所谓software timer就是说该timer是基于系统tick的）；  
NET\_TX\_SOFTIRQ和NET\_RX\_SOFTIRQ是用于网卡数据收发的；  
BLOCK\_SOFTIRQ和BLOCK\_IOPOLL\_SOFTIRQ是用于block device的；  
SCHED\_SOFTIRQ用于多CPU之间的负载均衡的；  
HRTIMER\_SOFTIRQ用于高精度timer的。RCU\_SOFTIRQ是处理RCU的。

### 2.2 Softirq 描述符 ###

softirq是静态定义的，也就是说系统中有一个定义softirq描述符的数组，而softirq number就是这个数组的index。这个概念和早期的静态分配的中断描述符概念是类似的。具体定义如下：

struct softirq_action
    { 
    	void	(*action)(struct softirq_action *);
    };
    static struct softirq_action softirq_vec[NR_SOFTIRQS] __cacheline_aligned_in_smp;

系统支持多少个软中断，静态定义的数组就会有多少个entry。\_\_\_\_cacheline\_aligned保证了在SMP的情况下，softirq\_vec是对齐到cache line的。softirq描述符非常简单，只有一个action成员，表示如果触发了该softirq，那么应该调用action回调函数来处理这个soft irq。对于硬件中断而言，其mask、ack等都是和硬件寄存器相关并封装在irq chip函数中，对于softirq，没有硬件寄存器，只有“软件寄存器”，定义如下：

typedef struct {  
        unsigned int __softirq_pending; 
    #ifdef CONFIG_SMP 
        unsigned int ipi_irqs[NR_IPI]; 
    #endif 
    } ____cacheline_aligned irq_cpustat_t;
    
    irq_cpustat_t irq_stat[NR_CPUS] ____cacheline_aligned;

ipi\_irqs这个成员用于处理器之间的中断，我们留到下一个专题来描述。\_\_softirq\_pending就是这个“软件寄存器”。softirq采用谁触发，谁负责处理的。例如：当一个驱动的硬件中断被分发给了指定的CPU，并且在该中断handler中触发了一个softirq，那么该CPU负责调用该softirq number对应的action callback来处理该软中断。因此，这个“软件寄存器”应该是每个CPU拥有一个（专业术语叫做banked register）。为了性能，irq\_stat中的每一个entry被定义对齐到cache line

### 2.3 Softirq注册 ###

通过调用open\_softirq接口函数可以注册softirq的action callback函数，具体如下：

void open_softirq(int nr, void (*action)(struct softirq_action *)) 
    {  
        softirq_vec[nr].action = action; 
    }

softirq\_vec是一个多CPU之间共享的数据，不过，由于所有的注册都是在系统初始化的时候完成的，那时候，系统是串行执行的。此外，softirq是静态定义的，每个entry（或者说每个softirq number）都是固定分配的，因此，不需要保护。

### 2.4 Softirq触发 ###

在linux kernel中，可以调用raise\_softirq这个接口函数来触发本地CPU上的softirq，具体如下：

void raise_softirq(unsigned int nr) 
    {  
        unsigned long flags;
    
        local_irq_save(flags); 
        raise_softirq_irqoff(nr); 
        local_irq_restore(flags); 
    }

虽然大部分的使用场景都是在中断handler中（也就是说关闭本地CPU中断）来执行softirq的触发动作，但是，这不是全部，在其他的上下文中也可以调用raise\_softirq。因此，触发softirq的接口函数有两个版本，一个是raise\_softirq，有关中断的保护，另外一个是raise\_softirq\_irqoff，调用者已经关闭了中断，不需要关中断来保护“soft irq status register”。  
所谓trigger softirq，就是在\_\_softirq\_pending（也就是上面说的soft irq status register）的某个bit置一。从上面的定义可知，\_\_softirq\_pending是per cpu的，因此不需要考虑多个CPU的并发，只要disable本地中断，就可以确保对，\_\_softirq\_pending操作的原子性。

具体raise\_softirq\_irqoff的代码如下：

inline void raise_softirq_irqoff(unsigned int nr) 
    {  
        __raise_softirq_irqoff(nr); －－－－－－－－－－－－－－－－（1）
    
    
        if (!in_interrupt()) 
            wakeup_softirqd();－－－－－－－－－－－－－－－－－－（2） 
    }

（1）\_\_raise\_softirq\_irqoff函数设定本CPU上的\_\_softirq\_pending的某个bit等于1，具体的bit是由soft irq number（nr参数）指定的。

（2）如果在中断上下文，我们只要set \_\_softirq\_pending的某个bit就OK了，在中断返回的时候自然会进行软中断的处理。但是，如果在context上下文调用这个函数的时候，我们必须要调用wakeup\_softirqd函数用来唤醒本CPU上的softirqd这个内核线程。具体softirqd的内容请参考下一个章节。  
2.5 Softirq disable/enable  
在linux kernel中，可以使用local\_irq\_disable和local\_irq\_enable来disable和enable本CPU中断。和硬件中断一样，软中断也可以disable，接口函数是local\_bh\_disable和local\_bh\_enable。虽然和想像的local\_softirq\_enable/disable有些出入，不过bh这个名字更准确反应了该接口函数的意涵，因为local\_bh\_disable/enable函数就是用来disable/enable bottom half的，这里就包括softirq和tasklet。

先看disable吧，毕竟禁止bottom half比较简单：

static inline void local_bh_disable(void) 
    {  
        __local_bh_disable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET); 
    }
    
    static __always_inline void __local_bh_disable_ip(unsigned long ip, unsigned int cnt) 
    {  
        preempt_count_add(cnt); 
        barrier(); 
    }

看起来disable bottom half比较简单，就是讲current thread info上的preempt\_count成员中的softirq count的bit field9～15加上一就OK了。

enable函数比较复杂，如下：

static inline void local_bh_enable(void) 
    {  
        __local_bh_enable_ip(_THIS_IP_, SOFTIRQ_DISABLE_OFFSET); 
    }
    
    void __local_bh_enable_ip(unsigned long ip, unsigned int cnt) 
    {  
        WARN_ON_ONCE(in_irq() || irqs_disabled());－－－－－－－－－－－（1） 
    
        preempt_count_sub(cnt - 1); －－－－－－－－－－－－－－－－－－（2）
    
        if (unlikely(!in_interrupt() && local_softirq_pending())) {  －－－－－－－（3） 
            do_softirq(); 
        }
    
        preempt_count_dec(); －－－－－－－－－－－－－－－－－－－－－（4） 
        preempt_check_resched(); 
    }

（1）disable/enable bottom half是一种内核同步机制。在硬件中断的handler（top half）中，不应该调用disable/enable bottom half函数来保护共享数据，因为bottom half其实是不可能抢占top half的。同样的，soft irq也不会抢占另外一个soft irq的执行，也就是说，一旦一个softirq handler被调度执行（无论在哪一个processor上），那么，本地的softirq handler都无法抢占其运行，要等到当前的softirq handler运行完毕后，才能执行下一个soft irq handler。注意：上面我们说的是本地，是local，softirq handler是可以在多个CPU上同时运行的，但是，linux kernel中没有disable all softirq的接口函数（就好像没有disable all CPU interrupt的接口一样，注意体会local\_bh\_enable/disable中的local的含义）。

说了这么多，一言以蔽之，local\_bh\_enable/disable是给进程上下文使用的，用于防止softirq handler抢占local\_bh\_enable/disable之间的临界区的。

irqs\_disabled接口函数可以获知当前本地CPU中断是否是disable的，如果返回1，那么当前是disable 本地CPU的中断的。如果irqs\_disabled返回1，有可能是下面这样的代码造成的：

local_irq_disable();
    
    …… 
    local_bh_disable();
    
    ……
    
    local_bh_enable(); 
    …… 
    local_irq_enable();

本质上，关本地中断是一种比关本地bottom half更强劲的锁，关本地中断实际上是禁止了top half和bottom half抢占当前进程上下文的运行。也许你会说：这也没有什么，就是有些浪费，至少代码逻辑没有问题。但事情没有这么简单，在local\_bh\_enable—>do\_softirq—>\_\_do\_softirq中，有一条无条件打开当前中断的操作，也就是说，原本想通过local\_irq\_disable/local\_irq\_enable保护的临界区被破坏了，其他的中断handler可以插入执行，从而无法保证local\_irq\_disable/local\_irq\_enable保护的临界区的原子性，从而破坏了代码逻辑。

in\_irq()这个函数如果不等于0的话，说明local\_bh\_enable被irq\_enter和irq\_exit包围，也就是说在中断handler中调用了local\_bh\_enable/disable。这道理是和上面类似的，这里就不再详细描述了。

（2）在local\_bh\_disable中我们为preempt\_count增加了SOFTIRQ\_DISABLE\_OFFSET，在local\_bh\_enable函数中应该减掉同样的数值。这一步，我们首先减去了（SOFTIRQ\_DISABLE\_OFFSET－1），为何不一次性的减去SOFTIRQ\_DISABLE\_OFFSET呢？考虑下面运行在进程上下文的代码场景：

……
    
    local_bh_disable
    
    ……需要被保护的临界区……
    
    local_bh_enable
    
    ……

在临界区内，有进程context 和softirq共享的数据，因此，在进程上下文中使用local\_bh\_enable/disable进行保护。假设在临界区代码执行的时候，发生了中断，由于代码并没有阻止top half的抢占，因此中断handler会抢占当前正在执行的thread。在中断handler中，我们raise了softirq，在返回中断现场的时候，由于disable了bottom half，因此虽然触发了softirq，但是不会调度执行。因此，代码返回临界区继续执行，直到local\_bh\_enable。一旦enable了bottom half，那么之前raise的softirq就需要调度执行了，因此，这也是为什么在local\_bh\_enable会调用do\_softirq函数。

调用do\_softirq函数来处理pending的softirq的时候，当前的task是不能被抢占的，因为一旦被抢占，下一次该task被调度运行的时候很可能在其他的CPU上去了（还记得吗？softirq的pending 寄存器是per cpu的）。因此，我们不能一次性的全部减掉，那样的话有可能preempt\_count等于0，那样就允许抢占了。因此，这里减去了（SOFTIRQ\_DISABLE\_OFFSET－1），既保证了softirq count的bit field9～15被减去了1，又保持了preempt disable的状态。

（3）如果当前不是interrupt context的话，并且有pending的softirq，那么调用do\_softirq函数来处理软中断。

（4）该来的总会来，在step 2中我们少减了1，这里补上，其实也就是preempt count-1。

（5）在softirq handler中很可能wakeup了高优先级的任务，这里最好要检查一下，看看是否需要进行调度，确保高优先级的任务得以调度执行。

### 2.6 Softirq的处理 ###

我们说softirq是一种defering task的机制，也就是说top half没有做的事情，需要延迟到bottom half中来执行。那么具体延迟到什么时候呢？这是本节需要讲述的内容，也就是说soft irq是如何调度执行的。

在上一节已经描述一个softirq被调度执行的场景，本节主要关注在中断返回现场时候调度softirq的场景。我们来看中断退出的代码，具体如下：

void irq_exit(void) 
    {  
    …… 
        if (!in_interrupt() && local_softirq_pending()) 
            invoke_softirq();
    
    …… 
    }

代码中“!in\_interrupt()”这个条件可以确保下面的场景不会触发sotfirq的调度：

（1）中断handler是嵌套的。也就是说本次irq\_exit是退出到上一个中断handler。当然，在新的内核中，这种情况一般不会发生，因为中断handler都是关中断执行的。

（2）本次中断是中断了softirq handler的执行。也就是说本次irq\_exit是不是退出到进程上下文，而是退出到上一个softirq context。这一点也保证了在一个CPU上的softirq是串行执行的（注意：多个CPU上还是有可能并发的）

我们继续看invoke\_softirq的代码：

static inline void invoke_softirq(void) 
    {  
        if (!force_irqthreads) {  
    #ifdef CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK 
            __do_softirq(); 
    #else 
            do_softirq_own_stack(); 
    #endif 
        } else {  
            wakeup_softirqd(); 
        } 
    }

force\_irqthreads是和强制线程化相关的，主要用于interrupt handler的调试（一般而言，在线程环境下比在中断上下文中更容易收集调试数据）。如果系统选择了对所有的interrupt handler进行线程化处理，那么softirq也没有理由在中断上下文中处理（中断handler都在线程中执行了，softirq怎么可能在中断上下文中执行）。本身invoke\_softirq这个函数是在中断上下文中被调用的，如果强制线程化，那么系统中所有的软中断都在sofirq的daemon进程中被调度执行。

如果没有强制线程化，softirq的处理也分成两种情况，主要是和softirq执行的时候使用的stack相关。如果arch支持单独的IRQ STACK，这时候，由于要退出中断，因此irq stack已经接近全空了（不考虑中断栈嵌套的情况，因此新内核下，中断不会嵌套），因此直接调用\_\_do\_softirq()处理软中断就OK了，否则就调用do\_softirq\_own\_stack函数在softirq自己的stack上执行。当然对ARM而言，softirq的处理就是在当前的内核栈上执行的，因此do\_softirq\_own\_stack的调用就是调用\_\_do\_softirq()，代码如下（删除了部分无关代码）：

asmlinkage void __do_softirq(void) 
    { 
    
    ……
    
        pending = local_softirq_pending();－－－－－－－－－－获取softirq pending的状态
    
        __local_bh_disable_ip(_RET_IP_, SOFTIRQ_OFFSET);－标识下面的代码是正在处理softirq
    
        cpu = smp_processor_id(); 
    restart: 
        set_softirq_pending(0); －－－－－－－－－清除pending标志
    
        local_irq_enable(); －－－－－－打开中断，softirq handler是开中断执行的
    
        h = softirq_vec; －－－－－－－获取软中断描述符指针
    
        while ((softirq_bit = ffs(pending))) { －－－－寻找pending中第一个被设定为1的bit 
            unsigned int vec_nr; 
            int prev_count;
    
            h += softirq_bit - 1; －－－－－－指向pending的那个软中断描述符
            vec_nr = h - softirq_vec;－－－－获取soft irq number 
            h->action(h);－－－－－－－－－指向softirq handler 
    
            h++; 
            pending >>= softirq_bit; 
        }
    
        local_irq_disable(); －－－－－－－关闭本地中断
    
        pending = local_softirq_pending();－－－－－－－－－－（注1） 
        if (pending) {  
            if (time_before(jiffies, end) && !need_resched() && 
                --max_restart) 
                goto restart;
    
            wakeup_softirqd(); 
        }
    
        __local_bh_enable(SOFTIRQ_OFFSET);－－－－－－－－－－标识softirq处理完毕 
    }

（注1）再次检查softirq pending，有可能上面的softirq handler在执行过程中，发生了中断，又raise了softirq。如果的确如此，那么我们需要跳转到restart那里重新处理soft irq。当然，也不能总是在这里不断的loop，因此linux kernel设定了下面的条件：  
（1）softirq的处理时间没有超过2个ms  
（2）上次的softirq中没有设定TIF\_NEED\_RESCHED，也就是说没有有高优先级任务需要调度  
（3）loop的次数小于 10次

因此，只有同时满足上面三个条件，程序才会跳转到restart那里重新处理soft irq。否则wakeup\_softirqd就OK了。这样的设计也是一个平衡的方案。一方面照顾了调度延迟：本来，发生一个中断，系统期望在限定的时间内调度某个进程来处理这个中断，如果softirq handler不断触发，其实linux kernel是无法保证调度延迟时间的。另外一方面，也照顾了硬件的thoughput：已经预留了一定的时间来处理softirq。