本文主要是介绍soft lockup问题的定位方法，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
我之前已经写了lockup问题的检测原理，https://blog.csdn.net/rikeyone/article/details/112004920，本来就来尝试梳理一下soft lockup问题触发场景和解决方法。
首先需要明确一点soft lockup是一类问题，引起它的原因也是各有不同，本文只是尝试做一些梳理，把一些具有共通性的特点的问题做一些总结，可能存在有不全面的地方。
第一种场景：spinlock死锁场景
对于这种场景，其实很好理解，当A-B/B-A死锁发生的时候，两个进程分别去获取对方持有的锁，那么又都是spinlock，我们知道spinlock是会关闭抢占的，并且是忙等待锁，最终会造成执行CPU上的watchdog线程无法被调度执行。这是比较好理解的一个场景。
针对这个场景如何识别呢，我们从内核crash的堆栈中是可以看得一二的，肯定会有一些进程的堆栈是处于获取锁的过程中的，可以在调用栈中看到spin_lock相关的一些函数调用。那么针对这一种场景，我们可以利用crash去查找到spinlock结构体，并定位持有该锁的进程，如果两个进程互相持有对方要获取的锁，那么基本确认是这种死锁类型了。
第二种场景：内核繁忙
所谓的内核繁忙，也就是说内核长时间的在处理事务，而watchdog得不到执行，那么假如我在自己的内核模块中写了一个死循环，那么是不是一定会触发soft lockup呢？其实不然，死循环执行并不一定会导致soft lockup，那是因为进程的运行是受到内核调度器管理的，并不是你写个死循环，它就会一直占用CPU不释放，这种理解是不对的。
那么什么情况下的内核繁忙才会引起soft lockup呢？
实际上，当我们禁止调度或者持有自旋锁之后，执行了一个很耗时的任务，那么就很可能会触发该问题，因为调度被关闭以后，CPU就归当前的进程所有了，watchdog线程也就无法得到调度了。
关于持有自旋锁后执行繁忙任务的场景，读者可能会觉得这一条应该被归于第一种场景。因为进程持有的锁在其他进程尝试获取时就相当于发生了死锁，那么就变成了第一种场景，不过我写在这里实际上是考虑的另一种情况：长时间持有自旋锁。
假如有进程A进入内核态后持有了spinlock，并运行了繁重的任务，需要耗时很长，并且一直也没有其他进程去获取该锁，那么它同样会因为内核繁忙而导致soft lockup。这里的关键就是spinlock暗含了关闭抢占的操作，导致持有锁的CPU上，watchdog线程无法被调度执行。
另一个例子：在NUMA系统中，对于一个共享变量的访问，如果采用了读写锁，有大量读者时，可能导致写锁一直获取不到，特别是NUMA系统中不同CPU对内存的访问时间也不同。
再比如：内核持有锁的情况下执行了大量对象的扫描、释放、申请动作等等。
第三种：虚拟机中资源获取受限
笔者是在云厂商工作，所以第三种呢，考虑到的是虚拟机场景， 通过redhat提供的一些案例中可知，如果发生soft lockup的地方是很随机没有规律的，并且有一些地方代码上看是不可能发生soft lockup的地方，那么就需要考虑是虚拟化引入的问题，对于物理机器来说，一个soft lockup很可能是内核的bug或者硬件的bug，而对于虚拟机场景，还有一种可能就行虚拟化机制带来的overcommit(especially memory overcommitment or other virtualization overheads）， 比如 hypervisor not scheduling virtual CPUs in timely manner。
IPI中断超时响应
在虚拟机场景下，对于soft lockup我遇到过多例都是soft lockup死在了ipi请求过程中，特别是函数smp_call_function_many中：
PID: 12263 TASK: ffff8803bbebdee0 CPU: 2 COMMAND: "kworker/u8:0"
bt: page excluded: kernel virtual address: ffffffffffffffff type: "cpu_online_map"#0 [ffff88043fd03cf8] machine_kexec at ffffffff8105c4cb#1 [ffff88043fd03d58] __crash_kexec at ffffffff81104a32#2 [ffff88043fd03e28] panic at ffffffff8169dc5f#3 [ffff88043fd03ea8] watchdog_timer_fn at ffffffff8112f651#4 [ffff88043fd03ee0] __hrtimer_run_queues at ffffffff810b4ae4#5 [ffff88043fd03f38] hrtimer_interrupt at ffffffff810b507f#6 [ffff88043fd03f80] local_apic_timer_interrupt at ffffffff81053895#7 [ffff88043fd03f98] smp_apic_timer_interrupt at ffffffff816b76bd#8 [ffff88043fd03fb0] apic_timer_interrupt at ffffffff816b5c1d--- <IRQ stack> ---#9 [ffff88000399b738] apic_timer_interrupt at ffffffff816b5c1d[exception RIP: smp_call_function_many+514]RIP: ffffffff810f99a2 RSP: ffff88000399b7e8 RFLAGS: 00000202RAX: 0000000000000003 RBX: 00000000000000fc RCX: ffff88043fd9adb8RDX: 0000000000000003 RSI: 0000000000000004 RDI: 0000000000000000RBP: ffff88000399b820 R8: ffff88017a1ee000 R9: ffffffff813227d9R10: ffff88043fd19c80 R11: ffffea00000c2100 R12: 0000000000000292R13: ffff88000399b798 R14: ffffea0010b1f842 R15: 0000000000000000ORIG_RAX: ffffffffffffff10 CS: 0010 SS: 0018
#10 [ffff88000399b828] native_flush_tlb_others at ffffffff8106e668
#11 [ffff88000399b878] flush_tlb_page at ffffffff8106e864
这种特例最后被发现就是虚拟机vcpu调度引发的问题
参考
https://access.redhat.com/articles/5008811
https://access.redhat.com/solutions/1503333
https://www.suse.com/support/kb/doc/?id=000018705
https://access.redhat.com/solutions/658783
这篇关于soft lockup问题的定位方法的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
