编者按： 随着 Linux 内核的不断更新迭代，代码变得越来越繁重。调度器是内核最核心的子系统之一，它的结构复杂，与其它子系统紧密耦合，这使得开发和调试变得越发困难。 Plugsched 是 Linux 内核调度器子系统热升级的 SDK，它可以实现在不重启系统、应用的情况下动态替换调度器子系统，毫秒级 downtime。本文整理 自 龙蜥大讲堂第 18 期 ， 精彩分享视频回放已上传至龙蜥官网 （首页-动态-视频） ，欢迎查看！

Plugsched 是 Linux 内核调度器子系统热升级的 SDK，它可以实现在不重启系统、应用的情况下动态替换调度器子系统，毫秒级 downtime。Plugsched 可以对生产环境中的内核调度特性动态地进行增、删、改，以满足不同场景或应用的需求，且支持回滚。目前已经在龙蜥社区开源了。

随着 Linux 内核的不断更新迭代，代码变得越来越繁重。调度器是内核最核心的子系统之一，它的结构复杂，与其它子系统紧密耦合，这使得开发和调试变得越发困难。而且，调度器内嵌在内核中，应用新的调度器需要更换内核，这在集群中代价比较昂贵。再者，目前不存在子系统范围的热升级方案，kpatch、livepatch 是函数粒度的热升级方案，eBPF 目前还不支持调度器。对于调度器而言，由于应用场景及其特征的多样性，使得调度策略的优化比较复杂，尤其在云场景下，不存在“一劳永逸”的策略，因此，允许用户定制调度器满足不同的场景是必要的。

基于以上背景，Plugsched 诞生了，它能将调度器子系统从内核中提取出来，以模块的形式对内核调度器进行热升级。通过对调度器模块的修改，能够针对不同业务定制化调度器，而且使用模块能够更敏捷的开发新特性和优化点，并且可以在不中断业务的情况下上线。

本文从 plugsched 的 背景、优势、应用场景和原理 四个方面展开 分享，通过一个实际案例体现出 plugsched 的价值所在，最后给大家进行了实际操作的演示，演示过程中，详细介绍了 plugsched 如何使用、每一步的操作如何进行以及背后的工作是什么。

最后，讲师与线上听众进行了 Q&A 互动，本文主要摘录以下 5 个问题：

A：安装调度器包后，相当于系统中存在两个调度器，一个是内核原有的调度器，另一个是新安装的调度器。安装新的调度器安装后，内核原有的调度器相当于被旁路掉了。当新的调度器包被卸载（回滚）后，内核原有的调度器相当于被重新 enable，会自动生效。

A：目前，上游社区还不支持调度器 eBPF 的 hook 点，即便是支持了，也只能支持局部策略的修改，可修改能力有限。而且 eBPF 不能实现很复杂的修改，它的检查机制很严格，不能实现复杂的逻辑，修改能力进一步受限。

A：ghOSt 与 plugsched 面向的场景不同，性能也不同。ghOSt 有两种工作模式，local 模式开销较大，每次调度要多经历一次上下文切换，即切入切出用户态调度器软件，所以只能在一些延迟要求不高的场景用。而 global 模式过度依赖 IPI，IPI 的开销会导致调度不及时，增加延时。再者，ghOSt 针对无内核开发经验的用户态软件开发者，容错性比较高，但是性能相对较差，只能用于部分场景。plugsched 依旧针对内核开发者，要求开发者有与传统内核同样的开发经验，但是为内核开发者降低开发、测试、上线、回滚的难度，性能好，能用于绝大部分场景。

A：对于模块化的开销，可以不需要太关注，因为这个过程是 offline 的，而且生成调度器模块后，可以持续修改和生成 RPM 包。对于它的开销，演示过程使用的环境是 64 核 CPU，生成调度器模块的时间大约是 2-3 分钟，应为它需要编译一次内核，开销并不是很高。

A：plugsched 支持安装多内核版本的调度器包，就像可以同时安装多个版本的内核一样。当系统重启后，plugsched 会自动识别并安装当前内核版本的调度器模块，即便是不存在对应内核版本的调度器，也不会安装其它内核版本的调度器模块。因此，系统重启或更换内核并没有什么影响。

关于回放和课件获取 

—— 完 ——