cgroup_mutex 是内核实现 cgroup 子系统而重度依赖的一把全局锁，这把全局锁在很多场景下会带来非常多的性能问题。具体这里不展开讲了，google 一下 cgroup_mutex deadlock，可以看到一堆 bugs report

最近线上恰好遇到一次机器死机的场景，后来分析发现和 cgroup_mutex 死锁有关（严格来说不叫死锁，叫夯死更合适一些），以此记录分析过程

1. 现象

机器存在大量的 D 进程，监控发现系统负载缓慢持续增高，应该是由于D进程持续不断地堆积，导致负载越来越高

所有与 cgroup_mutex 打交道的地方，都会卡死，比如简单来说 cat /proc/self/cgroup 会立即进入夯死状态，进程无法 kill -9 杀掉

我们通过一些艰难的内核栈跟踪，终于捕捉到了内核临死前的锁持有的状态（此处省略掉1万字跟踪过程）

2. 内核栈分析

读过内核源码或者了解内核原理的应该知道，vfs_write 是内核文件系统的抽象层。vfs_write 接着调用 cgroup_file_write，这个说明当前进程正在写 cgroup 文件系统，然后在写过程中，陷入 synchronize_sched，进程被换出，然后应该是一直卡在这里了。

但是真正导致系统死机的，并不是 synchronize_sched 这个地方，二是一个很复杂的链，触发场景：

1. 1. 进程持有 cgroup_mutex

1. 进程尝试获取其他锁，或者进入睡眠态
2. 进程 cfs 时间片被 throt，导致进程无法重新获得 cpu 的控制权，cgroup_mutex 无法释放

cgroup_mutex 是一把极大的锁，几乎任何 cgroup 操作都会涉及到这把锁的操作。在我们这个场景里，进程持有 cgroup_mutex 之后陷入 __wait_rcu，其他进程在尝试持有 cgroup_mutex 的时候几乎全部都夯住了

论文原址：https://www.cs.jhu.edu/~erfan/files/cts.pdf

cts 提出了一种优化长尾延迟的方法，通过改进 linux 内核默认的 cfs 调度器，引入线程调度机制

论文的一些要点：

• It has been proven that FCFS scheduling of threads leads to lower tail latency
• Experiments show that CFS policies lead to LCFS scheduling, aggravating tail latency
• CTS policies ensure FCFS thread scheduling, which yields lower tail latency.
• CTS enforces our policies while maintaining the key features of the Linux scheduler
• Experimental results show that CTS significantly outperforms the Linux scheduler

延迟敏感型的程序，通常有两种进程模型，一种是 thread-driven，另一种是 event-driven。前者很容易理解，起1个线程来服务一个请求，模型很简单。后者相对复杂一些，比如 libev，libevent 都是用来实现 event-driven 架构的基础库，通过 io 多路复用技术，将 io 线程和 worker 线程分离，io 线程专注数据转发，worker 线程专注业务逻辑处理

但是这个 io 线程很关键，如果数据 ready，但是得不到处理，会导致严重的长尾延迟。io 密集型的程序瓶颈不在 cpu，而是 io，CPU 上的时间片消耗是非常小的，远小于1ms，因而这种进程理论上应该优先获得响应

调度单元有三种状态：

1. 睡眠：不在 CPU 运行队列里
2. PENDING：调度单元被唤醒，比如网络数据包到达，IO ready等，进程被唤醒，进入运行队列，但是还没得到 CPU 时间片
3. 运行：调度单元得到 CPU 控制权，开始运行

调度延时其实就是指进程被唤醒，进入运行队列到得到 CPU 时间片之间的等待时间，也就是处于 PENDING 状态的时间

Linux 通过一个红黑树来维护所有进程的状态，每个 CPU 都会有一个运行队列，管理所有进程和进程组【注意，进程组也是内核的一个基本的调度单元】

每个调度单元都会有一个 vruntime 的属性，用来记录当前调度单元以运行的虚拟时间

我们在追查线上问题的时候，经常会碰到 cpu iowait 很高的 case，并且通常这种机器伴随着难登录、操作卡顿等现象，一看 cpu idle 还非常低，以为机器 cpu 被打爆了

其实不然，真正的罪魁祸首是 io，而不是 cpu。你看到的 cpu idle 很低，其实是因为部分 idle 时间被算到了 iowait 里面，导致看起来 cpu idle 很低而已。而纯粹的 iowait 很高，并不会引起系统卡顿，如果你发现系统卡顿，大概率是因为 io 异常的磁盘正好是根分区而已，不过今天我们不讨论 io，只讨论 cpu

那么问题来了，cpu iowait 到底是算 busy 还是 idle？

1. 如果 cpu iowait 不算 busy，那衡量一个 cpu 的繁忙程度的指标到底是什么？
2. 如果 cpu iowait 算 busy，这和直觉又不符合啊？既然是 io wait，cpu 都被切换出去执行其他进程了，又何来 busy 一说
3. 初次之外，内核是如何统计 cpu iowait 的？

https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/

The Linux Scheduler: a Decade of Wasted Cores – Lozi et al. 2016

This is the first in a series of papers from EuroSys 2016. There are three strands here: first of all, there’s some great background into how scheduling works in the Linux kernel; secondly, there’s a story about Software Aging and how changing requirements and maintenance can cause decay; and finally, the authors expose four bugs in Linux scheduling that caused cores to remain idle even when there was pressing work waiting to be scheduled. Hence the paper title, “A Decade of Wasted Cores.”

In our experiments, these performance bugs caused many-fold performance degradation for synchronization-heavy scientific applications, 13% higher latency for kernel make, and a 14-23% decrease in TPC-H throughput for a widely used commercial database.

目前cpu亲缘性设置有两种方式：

1. 通过sched_setaffinity()函数将进程绑定到某些cpu上运行
2. 讲进程加入到cpuset控制组，通过修改cpuset.cpus参数来实现亲缘性设置

但是有一点需要注意的是，通过sched_setaffinity设置的cpu_mask不允许超出cpuset.cpus的范围，超出部分是无效的。

举例，进程A所在的cpuset控制组cpuset.cpus参数值是0,1,2,3,4，但是进程运行期间调用sched_setaffinity()修改cpu_mask为0,1,2,4,7。因为7并不在cpuset.cpus范围里，所以内核会把7忽略掉，最终进程只能在0,1,2,4这几个CPU上运行。