soft lockup是指CPU被内核代码占用，导致无法执行其他进程，即CPU无法进行调度的现象。内核增强了soft lockup检测功能，提供了更为详尽的日志信息，能够更迅速地定位问题原因，从而采取相应的措施进行修复或优化，提高系统的稳定性和可靠性。
使用限制
内核：ANCK 5.10-017及以上版本。
soft lockup检测原理
内核为每个CPU分配一个定时执行的高优先级watchdog内核线程。如果该线程未能在设定期限内获得调度，则表明发生了soft lockup。
任务的优先级从左至右依次降低：硬中断、软中断、实时内核线程、普通内核线程、用户进程。
低优先级的任务不能抢占高优先级任务。
内核对中断处理的时序
一般情况下，内核对中断的处理时序图如下所示。
功能增强的soft lockup场景说明
soft lockup检测的是硬中断+软中断+内核线程的总时间，主要关注以下三种场景。
场景 | 描述 | 分析说明 |
CASE#1 | 软中断执行时间过长。 | 软中断的优先级高于内核线程，意味着在执行软中断时不会调度watchdog线程。因此，若软中断的执行时间过长，可能会导致soft lockup现象的发生。 |
CASE#2 | 硬中断+软中断执行时间过长。 | 与案例#1类似。不同之处在于，可能存在大量中断，内核持续处理中断，导致硬中断+软中断的执行时间较长，从而使得watchdog线程无法获得调度，最终可能导致soft lockup的发生。 |
CASE#3 | 内核线程执行时间过长。 | 最常见的soft lockup，也是内核soft lockup检测机制的检测目标。Alibaba Cloud Linux搭载的ANCK（Alibaba Cloud Kernel）内核为不可抢占内核，一旦进入内核态，除非内核任务执行结束后返回用户态或内核任务主动进行调度，否则内核将不会调度其他任务的执行，这意味着watchdog线程也不会被调度。在内核线程执行耗时的计算、死循环、长时间自旋等待锁等情况下，通常可以从Call Tree中直接看出原因。 |
出现soft lockup的3种场景的时序图如下所示。
功能增强的soft lockup使用说明
执行以下命令，查看内核日志。
dmesg功能增强的soft lockup检测机制会在发生soft lockup后输出以下信息。
watchdog: BUG: soft lockup - CPU#28 stuck for 23s! [fio:83921]
CPU#28 Utilization every 4s during lockup:
#1: 0% system, 0% softirq, 100% hardirq, 0% idle
#2: 0% system, 0% softirq, 100% hardirq, 0% idle
#3: 0% system, 0% softirq, 100% hardirq, 0% idle
#4: 0% system, 0% softirq, 100% hardirq, 0% idle
#5: 0% system, 0% softirq, 100% hardirq, 0% idle根据输出信息，判断soft lockup的具体原因的规则如下：
如果硬中断（hardirq）利用率较高，则表明是中断风暴。功能增强的soft lockup检测机制当检测到硬中断时间占比高于50%时会额外输出最高频的前5个中断，如下所示。
[ 638.873494] CPU#9 Detect HardIRQ Time exceeds 50%. Most frequent HardIRQs: [ 638.873994] #1: 330945 irq#7 [ 638.874236] #2: 31 irq#82 [ 638.874493] #3: 10 irq#10 [ 638.874744] #4: 2 irq#89 [ 638.874992] #5: 1 irq#102如果软中断（softirq）利用率很高，则表明是软中断处理时间过长。
如果system利用率很高，则表明是内核任务执行时间过长。
增强后的soft lockup检测机制实战指南
案例一：中断风暴导致的soft lockup。
以下5行信息顺序输出了soft lockup期间每个统计周期内CPU的状态，从左往右分别是CPU处理内核任务、处理软中断、处理硬中断和空闲状态的时间占比。可以看出导致soft lockup的原因是中断风暴（100% hardirq），同时也可以看出最高频的中断是
irq#129，具体如下所示。
通过
cat /proc/interrupts | awk '{print($1 $NF);}'命令查看接口发现，最高频的irq#129是nvme2中断，具体如下所示。
案例二：软中断处理时间过长。
soft lockup期间CPU处理软中断的时间占比达到了100%（100% softirq），由此可以基本判断，问题是由
fq_flush_timeout函数的执行时间过长导致的，接下来可以通过分析该函数的逻辑以进一步排查问题，具体如下所示。