分析core不是一件容易的事情。试想，一个系统运行了很长一段时间，在这段时间里，系统会积累大量正常、甚至不正常的状态。这个时候如果系统突然出现了一个问题，那这个问题十有八九跟长时间积累下来的状态有关系。分析core，就是分析出问题时，系统产生的“快照”，追溯历史，找出问题发生源头。这有点像是从案发现场，推导案发经过一样。
soft lockup！
今天这个“案件”，我们从soft lockup说起。
soft lockup是内核实现的夯机自我诊断功能。这个功能的实现，和线程的优先级有关系。
这里我们假设有三个线程A、B、和C。他们的优先级关系是A<B<C。这意味着C优先于B执行，B优先于A执行。这个优先级关系，如果倒过来叙述，就会产生一个规则：如果C不能执行，那么B也没有办法执行，如果B不能执行，那基本上A也没法执行。
soft lockup实际上就是对这个规则的实现：soft lockup使用一个内核定时器（C线程），周期性地检查，watchdog（B线程）有没有正常运行。如果没有，那就意味着普通线程（A线程）也没有办法正常运行。这时内核定时器（C线程）会输出类似上图中的soft lockup记录，来告诉用户，卡在cpu上的，有问题的线程的信息。
具体到这个“案件”，卡在cpu上的线程是python，这个线程正在刷新tlb缓存。
老搭档ipi和tlb
如果我们对所有夯机问题的调用栈做一个统计的话，我们肯定会发现，tlb和ipi是一对形影不离的老搭档。其实这不是偶然的。系统中，相对于内存，tlb是处理器本地的cache。这样的共享内存和本地cache的架构，必然会提出一致性的要求。如果每个处理器的tlb“各自为政”的话，那系统肯定会乱套。满足tlb一致性的要求，本质上来说只需要一种操作，就是刷新本地tlb的同时，同步地刷新其他处理器的tlb。系统正是靠tlb和ipi这对老搭档的完美配合来完成这个操作的。
这个操作本身的代价是比较大的。一方面，为了避免产生竞争，线程在刷新本地tlb的时候，会停掉抢占。这就导致一个结果：其他的线程，当然包括watchdog线程，没有办法被调度执行（soft lockup）。另外一方面，为了要求其他cpu同步地刷新tlb，当前线程会使用ipi和其他cpu同步进展，直到其他cpu也完成刷新为止。其他cpu如果迟迟不配合，那么当前线程就会死等。
不配合的cpu
为什么其他cpu不配合去刷新tlb呢？理论上来说，ipi是中断，中断的优先级是很高的。如果有cpu不配合去刷新tlb，基本上有两种可能：一种是这个cpu刷新了tlb，但是做到一半也卡住了；另外一种是，它根本没有办法响应ipi中断。
通过查看系统中所有占用cpu的线程，可以看到cpu基本上在做三件事情：idle，正在刷新tlb，和正在运行java程序。其中idle的cpu，肯定能在需要的时候，响应ipi并刷新tlb。而正在刷新tlb的cpu，因为停掉了抢占，且在等待其他cpu完成tlb刷新，所以在重复输出soft lockup记录。这里问题的关键，是运行java的cpu，这个我们在下一节讲。
来源：oschina
链接：https://my.oschina.net/u/3895371/blog/1837824