问题不是出在upstream的版本上，而是内部开发的一个产品。在KVM这个系统里面，很多时候牵一发动全身，某些改动貌似是正确的，其实则不然，内核的其他模块也是类似的系统化，Jike说的“正是内核的开发门槛很高才保证了内核当前的质量”也是有道理的。
进入正题，产品要求VCPU进入guest之前需要等待响应，当存在响应的时候...
代码版本：linux-git v4.10.0-rc3
1.kvm clock时钟
struct pvclock_vcpu_time_info {
u32 version;
u32 pad0;
//guest的TSC时间戳，在kvm_guest_time_update中会被更新
u64 tsc_timestamp;
//guest的墙上时间（1970年距今的绝对日期），和上者在一起更新
//system_time = kernel_ns + v->kvm->arch.kv...
一. epoll用户态使用规范
epoll有2种工作方式：LT和ET。
LT（level triggered，水平触发）是缺省的工作方式，并且同时支持block和no-block socket.在这种做法中，内核告诉你一个文件描述符是否就绪了，然后你可以对这个就绪的fd进行IO操作。如果你不作任何操作，内核还是会继续通知你的，所以，这种模式编程出错误可能...
KVM下steal_time源代码分析
代码版本：https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git branch v4.3
刚好有人在其他文章评论下问到steal_time机制，顺便看了一下，总结如下。
steal_time原意是指在虚拟化环境下，hypervisor窃取的vm中的时间，严格讲就是VCPU没有运行的时间。
在guest中执行to...
还是神奇的进程调度问题引发的，参看Linux进程组调度机制分析，组调度机制是看清楚了，发现在重启过程中，很多内核调用栈阻塞在了double_rq_lock函数上，而double_rq_lock则是load_balance触发的，怀疑当时的核间调度出现了问题，在某个负责场景下产生了多核互锁，后面看了一下CPU负载平衡下的代码实现，写一下总结。
...
又碰到一个神奇的进程调度问题，在系统重启过程中，发现系统挂住了，过了30s后才重新复位，真正系统复位的原因是硬件看门狗重启的系统，而非原来正常的reboot流程。硬件狗记录的复位时间，将不喂狗的时间向前推30s分析串口记录日志，当时的日志就打印了一句话：“sched: RT throttling activated”。
从linux-3.0.101-0.7....
死锁就是多个进程（线程）因为等待别的进程已占有的自己所需要的资源而陷入阻塞的一种状态，死锁状态一旦形成，进程本身是解决不了的，需要外在的推动，才能解决，最重要的是死锁不仅仅影响进程业务，而且还会占用系统资源，影响其他进程。所以内核中设计了内核死锁检测机制，一旦发现死锁进程，就重启OS，快刀斩乱麻解...
问题终于处理清楚了，如此坑爹的问题，陆陆续续的搞了有近月的时间，现在有时间写一个过程与总结。
问题现象：进程H需要每隔10s发消息给M（类似watchdog的功能），否则就会有功能异常的告警，业务发现了异常的告警，恰好OS监控日志中记录下了进程H当时是D状态，持续了约20s就恢复过来了，然后就没有然后，啥日志也没有...
CPU的亲和性， 就是进程要在指定的 CPU 上尽量长时间地运行而不被迁移到其他处理器，亲和性是从affinity翻译过来的，应该有点不准确，给人的感觉是亲和性就是有倾向的意思，而实际上是倒向的意思，称为CPU关联性更好，程序员的土话就是绑定CPU，绑核。
在多核运行的机器上，每个CPU本身自己会有缓存，缓存着进程使用的...
OenHan