2、操作系统-中断

可屏蔽中断和非屏蔽中断区别

​ 按照是否可以 被屏蔽,可将中断分为两大类:不可屏蔽中断(又叫非屏蔽中断)和可屏蔽中断。

不可屏蔽中断源一旦提出请求,cpu必须无条件响应,而对于可屏蔽中断源的请求,cpu可以响应,也可以不响应。cup一般设置两根中断请求输入线:可屏蔽中断请求INTR(Interrupt Require)和不可屏蔽中断请求NMI(Nonmaskable Interrupt)。对于可屏蔽中断,除了受本身的屏蔽位的控制外,还都要受一个总的控制,即CPU标志寄存器中的中断允许标志位IF(Interrupt Flag)的控制,IF位为1,可以得到CPU的响应,否则,得不到响应。IF位可以有用户控制,指令STI或Turbo c的Enable()函数,将IF位置1(开中断),指令CLI或Turbo_c 的Disable()函数,将IF位清0(关中断)。

典型的非屏蔽中断源的例子是电源掉电,一旦出现,必须立即无条件地响应,否则进行其他任何工作都是没有意义的。典型的可屏蔽中断源的例子是打印机中断,CPU对打印机中断请求的响应可以快一些,也可以慢一些,因为让打印机等待儿是完全可以的。

中断是什么?

先来看看什么是中断?在计算机中,中断是系统用来响应硬件设备请求的一种机制,操作系统收到硬件的中断请求,会打断正在执行的进程,然后调用内核中的中断处理程序来响应请求。

中断首先是处理器提供的一种响应外设请求的机制。一个外设通过产生一种电信号通知中断控制器,中断控制器再向处理器发送相应的信号。处理器检测到了这个信号后就会打断自己当前正在做的工作,转而去处理这次中断(所以才叫中断)。当然在转去处理中断和中断返回时都有保护现场和返回现场的操作 ,这里不赘述,我在下面问题的回答里解释过一些,可以参考:

为什么系统调用时要把一些寄存器保存到内核栈又从内核栈恢复?

不同的设备会对应不同的中断号,不同的中断也会有不同的中断处理函数,中断处理函数一般在设备驱动注册时一同注册,这样一来哪个设备有了事件就能产生对应的中断,并找到对应的中断处理程序来执行了。

一个硬件中断的大致过程描述是下面这样(非绝对,依具体情况而定,意会一下即可):

+---------+   产生中断      +----------+   通知    +-----+
| 硬件设备 | -------------> | 中断控制器 | -------> | CPU |
+---------+                +----------+          +-----+
                                                    |
                                                    V
                                                 [中断内核]
                                                    |
                                                    V
                       [是否存在中断处理程序?] <--- do_IRQ()
                                 |
                         +-------+-------+
                         |Y             N|
                         V               |
                  handle_IRQ_event       |
                         |               |
                         V               |
                   执行中断处理程序         |
                         |               V
                         +----------> irq_exit ----> 恢复现场 .....

上面的解释可能过于学术了,容易云里雾里,我就举个生活中取外卖的例子。

小林中午搬完砖,肚子饿了,点了份白切鸡外卖。虽然平台上会显示配送进度,但是我也不能一直傻傻地盯着呀,时间很宝贵,当然得去干别的事情,等外卖到了配送员会通过「电话」通知我,电话响了,我就会停下手中地事情,去拿外卖。

这里的打电话,其实就是对应计算机里的中断,没接到电话的时候,我可以做其他的事情,只有接到了电话,也就是发生中断,我才会停下当前的事情,去进行另一个事情,也就是拿外卖。

从这个例子,我们可以知道,中断是一种异步的事件处理机制,可以提高系统的并发处理能力。

操作系统收到了中断请求,会打断其他进程的运行,所以中断请求的响应程序,也就是中断处理程序,要尽可能快的执行完,这样可以减少对正常进程运行调度地影响。

而且,中断处理程序在响应中断时,可能还会「临时关闭中断」,这意味着,如果当前中断处理程序没有执行完之前,系统中其他的中断请求都无法被响应,也就说中断有可能会丢失,所以中断处理程序要短且快。

还是回到外卖的例子,小林到了晚上又点起了外卖,这次为了犒劳自己,共点了两份外卖,一份小龙虾和一份奶茶,并且是由不同地配送员来配送,那么问题来了,当第一份外卖送到时,第一位配送员给我打了长长的电话,说了一些杂七杂八的事情,比如给个好评等等,但如果这时第二位配送员也想给我打电话。

很明显,这时第二位配送员因为我在通话中(相当于关闭了中断响应),自然就无法打通我的电话,他可能尝试了几次后就走掉了(相当于丢失了一次中断)

什么是软中断?

前面我们也提到了,中断请求的处理程序应该要短且快,这样才能减少对正常进程运行调度地影响,而且中断处理程序可能会暂时关闭中断,这时如果中断处理程序执行时间过长,可能在还未执行完中断处理程序前,会丢失当前其他设备的中断请求。

在中断处理时CPU没法处理其它事物,

那 Linux 系统为了解决中断处理程序执行过长和中断丢失的问题,将中断过程分成了两个阶段,分别是「上半部和下半部分」

  • 上半部用来快速处理中断,一般会暂时关闭中断请求,主要负责处理跟硬件紧密相关或者时间敏感的事情。
  • 下半部用来延迟处理上半部未完成的工作,一般以「内核线程」的方式运行。

前面的外卖例子,由于第一个配送员长时间跟我通话,则导致第二位配送员无法拨通我的电话,其实当我接到第一位配送员的电话,可以告诉配送员说我现在下楼,剩下的事情,等我们见面再说(上半部),然后就可以挂断电话,到楼下后,在拿外卖,以及跟配送员说其他的事情(下半部)。

这样,第一位配送员就不会占用我手机太多时间,当第二位配送员正好过来时,会有很大几率拨通我的电话。

再举一个计算机中的例子,常见的网卡接收网络包的例子。

于网卡来说,如果每次网卡收包时中断的时间都过长,那很可能造成丢包的可能性。( 因为中断处理程序在处理中断请求的时候,会临时关闭中断。。也就是此时如果网卡受到其他包时候,控制器无法继续向cpu发送其他中断信号)

当然我们不能完全避免丢包的可能性,以太包的传输是没有100%保证的,所以网络才有协议栈,通过高层的协议来保证连续数据传输的数据完整性(比如在协议发现丢包时要求重传)。

但是即使有协议保证,那我们也不能肆无忌惮的使用中断,中断的时间越短越好,尽快放开处理器,让它可以去响应下次中断甚至进行调度工作。

对于网卡收包来说:

网卡收到网络包后,会通过硬件中断通知内核有新的数据到了,于是内核就会调用对应的中断处理程序来响应网卡发出的中断信号,为了让中断的处理事件的事件越短越好,我们将中断处理事件分成了上下两部分:

上半部:网卡收到数据包,通知内核数据包到了,中断处理将只要把网卡的数据读到内存中,然后更新一下硬件寄存器的状态,比如把状态更新为表示数据已经读到内存中的状态值。

下半部:软中断就是下半部使用的一种机制,它通过软件模仿硬件中断的处理过程,但是和硬件没有关系,单纯的通过软件达到一种异步处理的方式。

接上半部,内核会触发一个软中断,把一些处理比较耗时且复杂的事情,交给「软中断处理程序」去做,也就是中断的下半部,其主要是需要从内存中找到网络数据,再按照网络协议栈,对网络数据进行逐层解析和处理,最后把数据送给应用程序。即解析处理数据包的工作则可以放到下半部去执行。

所以,中断处理程序的上部分和下半部可以理解为:

  • 上半部直接处理硬件请求,也就是硬中断,主要是负责耗时短的工作,特点是快速执行;
  • 下半部是由内核触发,也就说软中断,主要是负责上半部未完成的工作,通常都是耗时比较长的事情,特点是延迟执行;

还有一个区别,硬中断(上半部)是会打断 CPU 正在执行的任务,然后立即执行中断处理程序,而软中断(下半部)是以内核线程的方式执行,并且每一个 CPU 都对应一个软中断内核线程,名字通常为「ksoftirqd/CPU 编号」,比如 0 号 CPU 对应的软中断内核线程的名字是 ksoftirqd/0

其它下半部的处理机制还包括tasklet,工作队列等。依据所处理的场合不同,选择不同的机制,网卡收包一般使用软中断。对应NET_RX_SOFTIRQ这个软中断,软中断不只是包括硬件设备中断处理程序的下半部,一些内核自定义事件也属于软中断,比如内核调度等、RCU 锁(内核里常用的一种锁)等。

网卡收包的中断过程

注意:之前提过

硬中断(上半部)是会打断 CPU 正在执行的任务,然后立即执行中断处理程序,

软中断(下半部)是以内核线程的方式执行,并且每一个 CPU 都对应一个软中断内核线程,名字通常为「ksoftirqd/CPU 编号」,比如 0 号 CPU 对应的软中断内核线程的名字是 ksoftirqd/0

1、网卡硬中断的注册

一个网卡收到数据包,它首先要做的事情就是通知处理器进行中断处理。 其实就是通知cpu去执行设备驱动程序中的中断处理程序代码

不同的外设有不同的中断和中断处理函数,所以要研究网卡的中断我们得以一个具体的网卡驱动为例,比如e1000。其模块初始化函数就是:

static int __init e1000_init_module(void)
{
        int ret;
        pr_info("%s - version %s\n", e1000_driver_string, e1000_driver_version);

        pr_info("%s\n", e1000_copyright);

        ret = pci_register_driver(&e1000_driver);
...
...
        return ret;
}
static int __init e1000_init_module(void)
{
        int ret;
        pr_info("%s - version %s\n", e1000_driver_string, e1000_driver_version);

        pr_info("%s\n", e1000_copyright);

        ret = pci_register_driver(&e1000_driver);
...
...
        return ret;
}

其中e1000_driver这个结构体是一个关键,它的赋值如下:

static struct pci_driver e1000_driver = {
        .name     = e1000_driver_name,
        .id_table = e1000_pci_tbl,
        .probe    = e1000_probe,
        .remove   = e1000_remove,
        .driver = {
                .pm = &e1000_pm_ops,
        },
        .shutdown = e1000_shutdown,
        .err_handler = &e1000_err_handler
};

其中很主要的一个方法就是.probe方法,也就是e1000_probe():

/**                                                                                                                                                                                            
 * e1000_probe - Device Initialization Routine                                                                                                                                                 
 * @pdev: PCI device information struct                                                                                                                                                        
 * @ent: entry in e1000_pci_tbl                                                                                                                                                                
 *                                                                                                                                                                                             
 * Returns 0 on success, negative on failure                                                                                                                                                   
 *                                                                                                                                                                                             
 * e1000_probe initializes an adapter identified by a pci_dev structure.                                                                                                                       
 * The OS initialization, configuring of the adapter private structure,                                                                                                                        
 * and a hardware reset occur.                                                                                                                                                                 
 **/
static int e1000_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
{
...
...
        netdev->netdev_ops = &e1000_netdev_ops;
        e1000_set_ethtool_ops(netdev);
...
...
}

这个函数很长,我们不都列出来,这是e1000主要的初始化函数,即使从注释都能看出来。我们留意其注册了netdev的netdev_ops,用的是e1000_netdev_ops这个结构体:

static const struct net_device_ops e1000_netdev_ops = {
        .ndo_open               = e1000_open,
        .ndo_stop               = e1000_close,
        .ndo_start_xmit         = e1000_xmit_frame,
        .ndo_set_rx_mode        = e1000_set_rx_mode,
        .ndo_set_mac_address    = e1000_set_mac,
        .ndo_tx_timeout         = e1000_tx_timeout,
...
...
};

这个e1000的方法集里有一个重要的方法,e1000_open,我们要说的中断的注册就从这里开始:

/**                                                                                                                                                                                            
 * e1000_open - Called when a network interface is made active                                                                                                                                 
 * @netdev: network interface device structure                                                                                                                                                 
 *                                                                                                                                                                                             
 * Returns 0 on success, negative value on failure                                                                                                                                             
 *                                                                                                                                                                                             
 * The open entry point is called when a network interface is made                                                                                                                             
 * active by the system (IFF_UP).  At this point all resources needed                                                                                                                          
 * for transmit and receive operations are allocated, the interrupt                                                                                                                            
 * handler is registered with the OS, the watchdog task is started,                                                                                                                            
 * and the stack is notified that the interface is ready.                                                                                                                                      
 **/
int e1000_open(struct net_device *netdev)
{
        struct e1000_adapter *adapter = netdev_priv(netdev);
        struct e1000_hw *hw = &adapter->hw;
...
...
        err = e1000_request_irq(adapter);
...
}

e1000在这里注册了中断:

static int e1000_request_irq(struct e1000_adapter *adapter){        struct net_device *netdev = adapter->netdev;        irq_handler_t handler = e1000_intr;        int irq_flags = IRQF_SHARED;        int err;        err = request_irq(adapter->pdev->irq, handler, irq_flags, netdev->name,......}

中断处理程序是写在设备驱动中的

如上所示,这个被注册到中断处理程序的硬中断处理函数,也就是handler,就是e1000_intr()。我们不展开这个中断处理函数看了,我们知道中断处理函数在这里被注册了,在网络包来的时候会触发这个中断函数。

到这里,网卡硬中断的注册完成

2、注册软中断

上面我们看到了网卡硬中断的注册,我们下面看一下软中断处理的注册。我们在一开始提到了网卡收包时使用的软中断是NET_RX_SOFTIRQ,我们就在内核中查找这个关键字,看看这个注册的位置在哪。踏破铁鞋无觅处,得来全不费工夫,原来这个注册的位置在这里:

/*                                                                                                                                                                                              *      Initialize the DEV module. At boot time this walks the device list and                                                                                                                  *      unhooks any devices that fail to initialise (normally hardware not                                                                                                                      *      present) and leaves us with a valid list of present and active devices.                                                                                                                 *                                                                                                                                                                                              */...static int __init net_dev_init(void){......     // open_softirq()函数就是注册软中断用的函数,向它指定软中断号NET_RX_SOFTIRQ和软中断处理函数 net_rx_action()就可         // 以完成注册了。        open_softirq(NET_TX_SOFTIRQ, net_tx_action);        open_softirq(NET_RX_SOFTIRQ, net_rx_action);......}

3、从硬中断到软中断

现在一个网络包来了,会产生中断,会执行do_IRQ。关于do_IRQ的实现有很多,不同硬件对中断的处理都会有所不同,但一个基本的执行思路就是:

void __irq_entry do_IRQ(unsigned int irq)  //do_IRQ[98]   void do_IRQ(struct pt_regs *regs, int irq){                                                                                                      irq_enter();//*** arch/sh/kernel/irq.c: |do_IRQ[185]   asmlinkage __irq_entry int do_IRQ(unsigned           //int irq, struct pt_regs *regs)                                                                             generic_handle_irq(irq);                                                                       irq_exit();                                                                            }

我们没必要都展开,让我们专注我们的问题。do_IRQ会执行上面e1000_intr这个中断处理函数,这个中断处理是属于上半部的处理,do_IRQ的结尾会调用irq_exit(),这是软中断和中断衔接的一个地方。我们重点说一下这里。

void irq_exit(void){        __irq_exit_rcu();        rcu_irq_exit();         /* must be last! */        lockdep_hardirq_exit();}static inline void __irq_exit_rcu(void){#ifndef __ARCH_IRQ_EXIT_IRQS_DISABLED        local_irq_disable();#else        lockdep_assert_irqs_disabled();#endif        account_irq_exit_time(current);        preempt_count_sub(HARDIRQ_OFFSET);        if (!in_interrupt() && local_softirq_pending())                invoke_softirq();        tick_irq_exit();}

在irq_exit()的第一步就是一个local_irq_disable(),也就是说禁止了中断,不再响应中断。因为下面要处理所有标记为要处理的软中断,关中断是因为后面要清除这些软中断,将CPU软中断的位图中置位的位清零,这需要关中断,防止其它进程对位图的修改造成干扰。??

然后preempt_count_sub(HARDIRQ_OFFSET),硬中断的计数减1,表示当前的硬中断到这里就结束了。但是如果当前的中断是嵌套在其它中断里的话,这次减1后不会计数清0,如果当前只有这一个中断的话,这次减1后计数会清0。注意这很重要。

因为接下来一步判断!in_interrupt() && local_softirq_pending(),第一个!in_interrupt()就是通过计数来判断当前是否还处于中断上下文中,如果当前还有未完成的中断,则直接退出当前中断 tick_irq_exit();。未完成的中断即后半部的执行在后续适当的时机再进行,这个“适当的时机”比如ksoftirqd守护进程的调度,或者下次中断到此正好不在中断上下文的时候等情况。

我们现在假设当前中断结束后没有其它中断了,也就是不在中断上下文了,且当前CPU有等待处理的软中断,即local_softirq_pending()也为真。那么执行invoke_softirq()。

static inline void invoke_softirq(void){        if (ksoftirqd_running(local_softirq_pending()))                return;        if (!force_irqthreads) {#ifdef CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK                /*                                                                                                                                                                                              * We can safely execute softirq on the current stack if                                                                                                                                        * it is the irq stack, because it should be near empty                                                                                                                                         * at this stage.                                                                                                                                                                               */                __do_softirq();#else                /*                                                                                                                                                                                              * Otherwise, irq_exit() is called on the task stack that can                                                                                                                                   * be potentially deep already. So call softirq in its own stack                                                                                                                                * to prevent from any overrun.                                                                                                                                                                 */                do_softirq_own_stack();#endif        } else {                wakeup_softirqd();        }}

这个函数的逻辑很简单,首先如果ksoftirqd正在被执行,那么我们不想处理被pending的软中断,交给ksoftirqd线程来处理,这里直接退出。

如果ksoftirqd没有正在运行,那么判断force_irqthreads,也就是判断是否配置了CONFIG_IRQ_FORCED_THREADING,是否要求强制将软中断处理都交给ksoftirqd线程。因为这里明显要在中断处理退出的最后阶段处理软中断,但是也可以让ksoftirqd来后续处理。如果设置了force_irqthreads,则不再执行__do_softirq(),转而执行wakeup_softirqd()来唤醒ksoftirqd线程,将其加入可运行队列,然后退出。

如果没有设置force_irqthreads,那么就执行__do_softirq():

asmlinkage __visible void __softirq_entry __do_softirq(void){......        pending = local_softirq_pending();        account_irq_enter_time(current);        __local_bh_disable_ip(_RET_IP_, SOFTIRQ_OFFSET);        in_hardirq = lockdep_softirq_start();restart:        /* Reset the pending bitmask before enabling irqs */        set_softirq_pending(0);        local_irq_enable();        h = softirq_vec;        while ((softirq_bit = ffs(pending))) {......        }        if (__this_cpu_read(ksoftirqd) == current)                rcu_softirq_qs();        local_irq_disable();        pending = local_softirq_pending();        if (pending) {                if (time_before(jiffies, end) && !need_resched() &&                    --max_restart)                        goto restart;                wakeup_softirqd();        }        lockdep_softirq_end(in_hardirq);        account_irq_exit_time(current);        __local_bh_enable(SOFTIRQ_OFFSET);        WARN_ON_ONCE(in_interrupt());        current_restore_flags(old_flags, PF_MEMALLOC);}

注意在函数开始时就先执行了一个__local_bh_disable_ip(RET_IP, SOFTIRQ_OFFSET),表示当前要处理软中断了,在这种情况下是不允许睡眠的,也就是不能进程调度。这点很重要,也很容易混淆,加上前面我们说的irq_exit()开头的local_irq_disable(),所以当前处在一个既禁止硬中断,又禁止软中断,不能睡眠不能调度的状态。很多人就容易将这种状态归类为“中断上下文”,我个人认为是不对的。从上面in_interrupt函数的定义来看,是否处于中断上下文和preempt_count对于中断的计数有关:

#define irq_count()     (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_MASK \                                 | NMI_MASK))#define in_interrupt()          (irq_count())

和是否禁止了中断没有直接的关系。虽然中断上下文应该不允许睡眠和调度,但是不能睡眠和调度的时候不等于in_interrupt,比如spin_lock的时候也是不能睡眠的(这是目前我个人观点)。但是很多程序员之所以容易一概而论,是因为对于内核程序员来讲,判断自己所编程的位置是否可以睡眠和调度是最被关心的,所以禁用了中断后不能调度和睡眠就很容易被归类为在中断上下文,实际上我个人认为这应该算一个误解,或者说是“变相扩展”后的说辞。一切还要看我们对中断上下文这个概念的界定,如果像in_interrupt那样界定,那关不关中断和是否处于中断上下文就没有直接的关系。

下面在__do_softirq开始处理软中断(执行每一个待处理的软中断的action)前还有一个很关键的地方,就是local_irq_enable(),这就打开了硬件中断,然后后面的软中断处理可以在允许中断的情况下执行。注意这时候__local_bh_disable_ip(RET_IP, SOFTIRQ_OFFSET)仍然有效,睡眠仍然是不允许的。

到这里我们可以看到,内核是尽量做到能允许中断就尽量允许,能允许调度就尽量允许,因为无情的禁止是对CPU资源最大的浪费,也是对外设中断的不负责。否则长期处于禁止中断的情况下,网卡大量丢包将是难免的,而这也将是制约成网卡实际速率的瓶颈。

系统里有哪些软中断?

在 Linux 系统里,我们可以通过查看 /proc/softirqs 的 内容来知晓「软中断」的运行情况,以及 /proc/interrupts 的 内容来知晓「硬中断」的运行情况。

接下来,就来简单的解析下 /proc/softirqs 文件的内容,在我服务器上查看到的文件内容如下:

img

你可以看到,每一个 CPU 都有自己对应的不同类型软中断的累计运行次数,有 3 点需要注意下。

第一点,要注意第一列的内容,它是代表着软中断的类型,在我的系统里,软中断包括了 10 个类型,分别对应不同的工作类型,比如 NET_RX 表示网络接收中断,NET_TX 表示网络发送中断、TIMER 表示定时中断、RCU 表示 RCU 锁中断、SCHED 表示内核调度中断。

第二点,要注意同一种类型的软中断在不同 CPU 的分布情况,正常情况下,同一种中断在不同 CPU 上的累计次数相差不多,比如我的系统里,NET_RX 在 CPU0 、CPU1、CPU2、CPU3 上的中断次数基本是同一个数量级,相差不多。

第三点,这些数值是系统运行以来的累计中断次数,数值的大小没什么参考意义,但是系统的中断次数的变化速率才是我们要关注的,我们可以使用 watch -d cat /proc/softirqs 命令查看中断次数的变化速率。

前面提到过,软中断是以内核线程的方式执行的,我们可以用 ps 命令可以查看到,下面这个就是在我的服务器上查到软中断内核线程的结果:

img

可以发现,内核线程的名字外面都有有中括号,这说明 ps 无法获取它们的命令行参数,所以一般来说,名字在中括号里到,都可以认为是内核线程。

而且,你可以看到有 4 个 ksoftirqd 内核线程,这是因为我这台服务器的 CPU 是 4 核心的,每个 CPU 核心都对应着一个内核线程。


如何定位软中断 CPU 使用率过高的问题?

要想知道当前的系统的软中断情况,我们可以使用 top 命令查看,下面是一台服务器上的 top 的数据:

img

上图中的黄色部分 si,就是 CPU 在软中断上的使用率,而且可以发现,每个 CPU 使用率都不高,两个 CPU 的使用率虽然只有 3% 和 4% 左右,但是都是用在软中断上了。

另外,也可以看到 CPU 使用率最高的进程也是软中断 ksoftirqd,因此可以认为此时系统的开销主要来源于软中断。

如果要知道是哪种软中断类型导致的,我们可以使用 watch -d cat /proc/softirqs 命令查看每个软中断类型的中断次数的变化速率。

img

一般对于网络 I/O 比较高的 Web 服务器,NET_RX 网络接收中断的变化速率相比其他中断类型快很多。

如果发现 NET_RX 网络接收中断次数的变化速率过快,接下里就可以使用 sar -n DEV 查看网卡的网络包接收速率情况,然后分析是哪个网卡有大量的网络包进来。

img

接着,在通过 tcpdump 抓包,分析这些包的来源,如果是非法的地址,可以考虑加防火墙,如果是正常流量,则要考虑硬件升级等。

总结

为了避免由于中断处理程序执行时间过长,而影响正常进程的调度,Linux 将中断处理程序分为上半部和下半部:

  • 上半部,对应硬中断,由硬件触发中断,用来快速处理中断;
  • 下半部,对应软中断,由内核触发中断,用来异步处理上半部未完成的工作;

Linux 中的软中断包括网络收发、定时、调度、RCU 锁等各种类型,可以通过查看 /proc/softirqs 来观察软中断的累计中断次数情况,如果要实时查看中断次数的变化率,可以使用 watch -d cat /proc/softirqs 命令。

每一个 CPU 都有各自的软中断内核线程,我们还可以用 ps 命令来查看内核线程,一般名字在中括号里面到,都认为是内核线程。

如果在 top 命令发现,CPU 在软中断上的使用率比较高,而且 CPU 使用率最高的进程也是软中断 ksoftirqd 的时候,这种一般可以认为系统的开销被软中断占据了。

这时我们就可以分析是哪种软中断类型导致的,一般来说都是因为网络接收软中断导致的,如果是的话,可以用 sar 命令查看是哪个网卡的有大量的网络包接收,再用 tcpdump 抓网络包,做进一步分析该网络包的源头是不是非法地址,如果是就需要考虑防火墙增加规则,如果不是,则考虑硬件升级等。

posted @ 2021-08-14 07:58  笨拙的小菜鸟  阅读(1024)  评论(0编辑  收藏  举报