共计 6388 个字符,预计需要花费 16 分钟才能阅读完成。
文 / 龙蜥社区内核开发人员 陈善佩、吴一昊、邓二伟
Plugsched 是 Linux 内核调度器子系统热降级的 SDK,它能够实现在不重启零碎、利用的状况下动静替换调度器子系统,毫秒级 downtime。Plugsched 能够对生产环境中的内核调度个性动静地进行增、删、改,以满足不同场景或利用的需要,且反对回滚。
基于 plugsched 实现的调度器热降级,不批改现有内核代码,就能取得较好的可批改能力,人造反对线上的老内核版本。如果提前在内核调度器代码的要害数据结构中退出 Reserve 字段,能够额定取得批改数据结构的能力,进一步晋升可批改能力。
Plugsched 开源链接:https://gitee.com/anolis/plug…
那么 Plugsched 诞生的背景或者想要解决的问题是什么?
咱们认为有以下 4 点:
- 利用场景不同,最佳调度策略不同。利用品种极大丰富,利用特色也是变幻无穷(throughput-oriented workloads, 𝜇s-scale latency critical workloads, soft real-time, and energy efficiency requirements),使得调度策略的优化比较复杂,不存在“一劳永逸”的策略。因而,容许用户定制调度器满足不同的场景是必要的。
- 调度器迭代慢。Linux 内核通过很多年的更新迭代,代码变得越来越沉重。调度器是内核最外围的子系统之一,它的结构复杂,与其它子系统严密耦合,这使得开发和调试变得越发艰难。此外,Linux 很少减少新的调度类,尤其是不太可能承受非通用或场景针对型的调度器,上游社区在调度畛域发展缓慢。
- 内核降级艰难。调度器内嵌(built-in)在内核中,上线调度器的优化或新个性须要降级内核版本。内核公布周期通常是数月之久,这将导致新的调度器无奈及时利用在生产零碎中。再者,要在集群范畴降级新内核,波及业务迁徙和停机降级,对业务方来说代价低廉。
- 无奈降级子系统。kpatch 和 livepatch 是函数粒度的热降级计划,可批改能力较弱,不能实现简单的逻辑改变;eBPF 技术在内核网络中广泛应用,但当初调度器还不反对 ebpf hook,未来即便反对,也只是实现部分策略的灵便批改,可批改能力同样较弱。
- Plugsched 能将调度器子系统从内核中提取进去,以模块的模式对内核调度器进行热降级。通过对调度器模块的批改,可能针对不同业务定制化调度器,而且应用模块可能更麻利的开发新个性和优化点,并且能够在不中断业务的状况下上线。
图 1 plugsched: 业务不中断
应用 plugsched 具备以下 6 大劣势:
- 与内核公布解耦:调度器版本与内核版本解耦,不同业务能够应用不同调度策略;建设继续运维能力,减速调度问题修复、策略优化落地;晋升调度畛域翻新空间,放慢调度器技术演进和迭代
- 可批改能力强:能够实现简单的调度个性和优化策略,能人之所不能
- 保护简略:不批改内核代码,或大量批改内核代码,放弃内核主线洁净整洁;在内核代码 Tree 外独立保护非通用调度策略,采纳 RPM 的模式公布和上线
- 简略易用:容器化的 SDK 开发环境,一键生成 RPM,开发测试简洁高效
- 向下兼容:反对老内核版本,使得存量业务也能及时享受新技术红利
- 高效的性能:毫秒级 downtime,可疏忽的 overhead。
Plugsched 利用案例
Plugsched 相比 kpatch 和 livepatch 可批改能力更强,热降级范畴更广,plugsched 是子系统范畴的热降级,而后者是函数级别的热降级。对于 plugsched 而言,无论是 bugfix,还是性能优化,甚至是个性的增、删、改,都可胜任。鉴于 plugsched 较强的可批改能力,它可利用到以下场景:
- 疾速开发、验证、上线新个性,稳固后放入内核主线
- 针对不同业务场景做定制优化,以 RPM 包的模式公布和保护非通用调度器个性
- 对立治理调度器热补丁,防止多个热补丁之间的抵触而引发故障
利用案例 1:新增 Group Identity 调度个性
Group Identity 是阿里云用于混部场景的调度个性,它基于 CFS 调度器减少了一颗存储低优先级工作的红黑树,而且会对每一个 cgroup 调配一个默认优先级,用户也可自行配置其优先级,当队列中存在高优先级工作时,低优先级工作会进行运行。咱们利用 plugsched 对 anck 4.19 的一个老版本内核(没有该调度个性)进行调度器热降级,并将 Group Identity 调度个性移植到生成的调度器模块中,波及 7 个文件,2500+ 行的批改量。
装置该调度器模块后,在零碎中创立两个 cpu cgroup A 和 B,并绑定同一个 CPU,别离设置最高和最低优先级,而后各自创立一个 busy loop 工作。实践上,当 A 中有工作执行时,B 中的工作会进行运行。此时用 top 工具查看该 CPU 利用率,发现只有一个利用率是 100% 的 busy loop 工作,阐明模块中的 Group Identity 个性已失效;而动静卸载该模块后,呈现了两个各占 50% CPU 的 busy loop 工作,阐明模块曾经生效。
利用案例 2:与内核公布解耦及定制化调度器
阿里云某客户应用的旧版本内核,因为该内核调度器对 load 的统计算法不合理,导致 CPU 利用率过高,尽管修复补丁曾经合入内核主线,然而新内核版本还未公布,而且业务方也不打算更换内核,因为集群中部署了大量的业务,降级内核老本较高。
除此之外,客户的内核开发人员对其混部业务场景(Group Identity 调度个性)进行了针对性的优化,想将优化内容合入内核主线。然而,阿里云内核开发人员发现,该优化内容在其它场景中有性能回退,属于非通用优化,因而不容许将优化内容合入主线。
于是,客户的内核开发人员应用 plugsched 将优化修复内容全副移植到调度器模块中,最初规模部署。该案例能够体现出 plugsched 的与内核公布解耦、定制化调度器的劣势。
那么 Plugsched 该如何应用?
目前,plugsched 默认反对 Anolis OS 7(内核 ANCK-4.19 版本)零碎,其它操作系统须要调整边界配置。为了加重搭建运行环境的复杂度,咱们提供了容器镜像和 Dockerfile,开发人员不须要本人去搭建开发环境。为了不便演示,这里购买了一台阿里云 ECS(64CPU + 128GB),并装置 Anolis OS 7.9 ANCK 零碎发行版,咱们将演示对其内核调度器进行热降级的过程。
1、登陆云服务器后,先装置一些必要的根底软件包:
# yum install anolis-repos -y # yum install podman kernel-debuginfo-$(uname -r) kernel-devel-$(uname -r) --enablerepo=Plus-debuginfo --enablerepo=Plus -y
2、创立长期工作目录,下载零碎内核的 SRPM 包:
# mkdir /tmp/work # uname -r 4.19.91-25.2.an7.x86_64 # cd /tmp/work
# wget https://mirrors.openanolis.cn/anolis/7.9/Plus/source/Packages/kernel-4.19.91-25.2.an7.src.rpm
3、启动并进入容器:
# podman run -itd --name=plugsched -v /tmp/work:/tmp/work -v /usr/src/kernels:/usr/src/kernels -v /usr/lib/debug/lib/modules:/usr/lib/debug/lib/modules docker.io/plugsched/plugsched-sdk # podman exec -it plugsched bash # cd /tmp/work
4、提取 4.19.91-25.1.al7.x86_64 内核源码:
# plugsched-cli extract_src kernel-4.19.91-25.2.an7.src.rpm ./kernel
5、进行边界划分与提取:
# plugsched-cli init 4.19.91-25.2.an7.x86_64 ./kernel ./scheduler
6、提取后的调度器模块代码在 ./scheduler/kernel/sched/mod 中,简略批改 __schedule 函数,而后编译打包成调度器 rpm 包:
diff --git a/kernel/sched/mod/core.c b/kernel/sched/mod/core.c
index f337607..88fe861 100644
--- a/kernel/sched/mod/core.c
+++ b/kernel/sched/mod/core.c
@@ -3235,6 +3235,8 @@ static void __sched notrace __schedule(bool preempt)
struct rq *rq;
int cpu;
+ printk_once("scheduler: Hi, I am the new scheduler!\n");
+
cpu = smp_processor_id();
rq = cpu_rq(cpu);
prev = rq->curr;
# plugsched-cli build /tmp/work/scheduler
7、将生成的 rpm 包拷贝到宿主机,退出容器,并装置调度器包,调度器日志显示新批改的调度器曾经失效:
# cp /usr/local/lib/plugsched/rpmbuild/RPMS/x86_64/scheduler-xxx-4.19.91-25.2.an7.yyy.x86_64.rpm /tmp/work
# exit
exit
# rpm -ivh /tmp/work/scheduler-xxx-4.19.91-25.2.an7.yyy.x86_64.rpm
# dmesg | tail -n 10
[878.915006] scheduler: total initialization time is 5780743 ns
[878.915006] scheduler module is loading
[878.915232] scheduler: Hi, I am the new scheduler!
[878.915232] scheduler: Hi, I am the new scheduler!
[878.915990] scheduler load: current cpu number is 64
[878.915990] scheduler load: current thread number is 626
[878.915991] scheduler load: stop machine time is 243138 ns
[878.915991] scheduler load: stop handler time is 148542 ns
[878.915992] scheduler load: stack check time is 86532 ns
[878.915992] scheduler load: all the time is 982076 ns
咱们通过以上晓得了 Plugsched 是什么、利用案例,那它实现原理是什么?
调度器子系统在内核中并非是一个独立的模块,而是内嵌在内核中,与内核其它局部严密相连。Plugsched 采纳“模块化”的思维:它提供了边界划分程序,确定调度器子系统的边界,把调度器从内核代码中提取到独立的目录中,开发人员可对提取出的调度器代码进行批改,而后编译成新的调度器内核模块,动静替换内核中旧的调度器。对子系统进行边界划分和代码提取,须要处理函数和数据,而后生成一个独立的模块。
对于函数而言,调度器模块对外出现了一些要害的函数,以这些函数为入口就能够进入模块中,咱们称之为接口函数。通过替换内核中的这些接口函数,内核就能够绕过原有的执行逻辑进入新的调度器模块中执行,即可实现函数的降级。模块中的函数,除了接口函数外,还有外部函数,其它的则是内部函数。
对于数据,调度器模块默认应用并继承内核中原有的数据,对于调度器重要的数据,比方运行队列状态等,能够通过状态重建技术主动从新初始化,这类数据属于公有数据,而其它则是共享数据。为了灵活性,plugsched 容许用户手动设置公有数据,手动设置的公有数据会在模块中保留定义,但须要对它们进行初始化。对于构造体而言,plugsched 将只被调度器拜访的构造体成员分类为外部成员,其它为非外部成员。调度器模块容许批改外部成员的语义,禁止批改非外部成员的语义。如果构造体所有成员都是外部成员,则调度器模块容许批改整个构造体。然而,倡议优先应用构造体中的保留字段,而不是批改现有成员。
设计方案
Plugsched 次要蕴含两大部分,第一局部是调度器模块边界划分与代码提取局部,第二局部是调度器模块热降级局部,这两局部是整个计划的外围。其整体设计方案如下:
图 2 plugsched 整体架构
首先进行的是调度器模块边界划分和代码提取流程,因为调度器自身并不是模块,因而须要明确调度器的边界能力将它模块化。边界划分程序会依据边界配置信息(次要蕴含代码文件、接口函数等信息)从内核源代码中将调度器模块的代码提取到指定目录,而后开发人员可在此基础上进行调度器模块的开发,最初编译生成调度器 RPM 包,并可装置在对应内核版本的零碎中。装置后会替换掉内核中原有的调度器,装置过程会经验以下几个要害过程:
- 符号重定位:解析模块对局部内核符号的拜访
- 栈安全检查:相似于 kpatch,函数替换前必须进行栈安全检查,否则会呈现宕机的危险。plugsched 对栈安全检查进行了并行和二分优化,晋升了栈安全检查的效率,升高了停机工夫
- 接口函数替换:用模块中的接口函数动静替换内核中的函数
- 调度器状态重建:采纳通用计划主动同步新旧调度器的状态,极大的简化数据状态的一致性保护工作
总结:基于以上介绍,整体来看,Plugsched 使得调度器从内核中解放出来,开发人员能够对调度器进行专项定制,而不局限于内核通用调度器;内核保护也变得更加轻松,因为开发人员只须要关注通用调度器的开发与迭代,定制化调度器可通过 RPM 包的模式进行公布;内核调度器代码也会变得简洁,无需再被各个场景的优化混同起来。
将来,plugsched 会反对新版本内核和其它平台,继续对其易用性进行优化,并提供更多的利用案例。最初,欢送更多的开发者能参加到 plugsched 中。
—— 完 ——
退出龙蜥社群
退出微信群:增加社区助理 - 龙蜥社区小龙(微信:openanolis_assis),备注【龙蜥】与你同在;退出钉钉群:扫描下方钉钉群二维码。欢送开发者 / 用户退出龙蜥社区(OpenAnolis)交换,独特推动龙蜥社区的倒退,一起打造一个沉闷的、衰弱的开源操作系统生态!
对于龙蜥社区
龙蜥社区(OpenAnolis)是由企事业单位、高等院校、科研单位、非营利性组织、集体等在被迫、平等、开源、合作的根底上组成的非盈利性开源社区。龙蜥社区成立于 2020 年 9 月,旨在构建一个开源、中立、凋谢的 Linux 上游发行版社区及翻新平台。
龙蜥社区成立的短期指标是开发龙蜥操作系统 (Anolis OS) 作为 CentOS 停服后的应答计划,构建一个兼容国内 Linux 支流厂商的社区发行版。中长期指标是摸索打造一个面向未来的操作系统,建设对立的开源操作系统生态,孵化翻新开源我的项目,凋敝开源生态。
目前,龙蜥 OS 8.4 已公布,反对 X86_64、Arm64、LoongArch 架构,欠缺适配飞腾、海光、兆芯、鲲鹏、龙芯等芯片,并提供全栈国密反对。
欢送下载:
https://openanolis.cn/download
退出咱们,一起打造面向未来的开源操作系统!
https://openanolis.cn