《吴一昊-调度器热升级 - OS2ATC.pdf》由会员分享,可在线阅读,更多相关《吴一昊-调度器热升级 - OS2ATC.pdf(27页珍藏版)》请在三个皮匠报告上搜索。
1、PLUGSCHED安全高效地热升级 Linux 调度器主讲人:吴一昊主讲人:吴一昊()龙蜥社区调度器负责人龙蜥社区调度器负责人20232023-0303-2323ASPLOS 23 ASPLOS 23-Efficient Scheduler Live Update for Linux Kernel with ModularizationEfficient Scheduler Live Update for Linux Kernel with Modularizationhttps:/https:/dl.acm.orgdl.acm.org/doidoi/10.1145/3582016.35820
2、54/10.1145/3582016.3582054Plusgched 目录1.背景和动机2.真实案例3.技术原理1.内核调度器背景2.热升级技术背景3.需要怎样的方案4.设计总览1.在离线混合部署2.多租户隔离3.用户态调度4.内核开销优化5.Tiny Sched等其它1.调度器模块化2.栈安全检查3.函数重定向4.数据升级4.方案验证背景:调度器Linux 调度器基础:多任务操作系统最基础的子系统复杂:Linux的非常复杂的一个子系统(27 KLOC,63 files)Linux调度器哲学:通用性场景:移动端,高性能计算(HPC),桌面,服务器等问题:例如在科学计算场景中,有1423%的吞
3、吐下降诉求:对云厂商而言,业务种类繁多,有必要定制优化调度器系统升级停机昂贵传统方案:重启系统,重新初始化硬件,重启应用商业应用停机:$5,600/分钟(平均)背景:热升级业界流行解决方案(Kpatch,livepatch,Ksplice)函数级(livepatch/kpatch)/指令级(Ksplice)支持修改少量代码(一般少于100 LOC)其他方案(PROTEOS,Orthus,LUCOS)组件级(PROTEOS)支持修改多个函数依赖微内核,不能用于商业Linux服务器系统级(Orthus,LUCOS,VM-PHU)依靠 virtual machine manager(VMM)Plug
4、sched 术语函数级热升级、指令级热升级、组件级热升级、系统级热升级、子系统级热升级动机:需要怎样的热升级方案模块化产品可以根据不同的场景来定制化调度器开发者可以专注于迭代开发,发布的负担比发布操作系统轻避免长停机时间和丢失调度状态信息安全不修改内核:修改内核会引入很多对系统的侵入性原子性:集成新调度器,要么全部成功,要么全部失败回滚栈安全:当内核处于安全状态时,才进行修改和升级语义等价:一份数据的语义在升级前后是相同的高效停机时间短:停机时间必须尽可能小低开销:对CPU、内存、内核几乎不引入任何开销易用性:开发者使用遍历,学习成本低系统设计:总览预处理阶段收集调度器子系统信息,决定模块边界
5、,生成模块代码。开发阶段修改代码,在目录里研发新的调度器。部署阶段安装包,模块寻找安全的时机替换调度器。真实案例 在离线混部在线业务对延迟敏感,离线业务对延迟不敏感Group Identity 方案基于多棵红黑树的CFS调度优先级策略通过热升级:某龙蜥合作伙伴量身定制优化了GIBVT+SMT expel 方案BVT(Borrowed-Virtual-Time)用于提升在线业务优先级基于 CFS BWC 压制离线,避免对在线的 SMT 干扰通过热升级:让云原生社区老版本内核也能使用兼容Group Identity 的技术现状/计划Group Identity 已为多个龙蜥社区合作伙伴量身优化,积
6、累的经验将回合 ANCK 主线。BVT+SMT expel 已发布到 Koordinator 社区,加入 Koordinator 社区即可享受龙蜥技术。真实案例 多租户隔离租户间存在SMT干扰,尤其邻居高负载时算力影响很大Core Sched 方案某龙蜥合作伙伴利用Core Sched 以物理核为单位调度任务允许同一租户的任务调度到一个物理核上通过热升级:让 4.19/5.10 内核获得 5.14 内核才有的Core Sched其他优化:优化CFS BWC,避免任务超额消费物理核资源现状/计划方案准备上线中稍后开源、放出二进制包、技术文章HT0HT1AIdleAABBCore 0Core 1C
7、ore 2N/AN/ACore 20.E+001.E+082.E+083.E+08No Core SchedCore Sched+Ht awared quotastdv(ns)100串行50并发80并发100并发02E+094E+096E+09No Core SchedCore Sched+Ht awared quotaavg(ns)100串行50并发80并发100并发真实案例 用户态调度用户态研发者希望参与调度研发,用户态调度使决策上移ghOSt 方案某龙蜥合作伙伴研究者利用ghOSt 框架研发调度策略。以中心化调度策略,降低调度延迟,提升负载均衡。通过热升级:让非上游主线的ghOSt 方案
8、可以得到生产部署。效果暂不公开现状/计划研发完成,已开源到Plugsched 的仓库中。合作伙伴下一步计划暂不公开。未来探索基于 scheduler eBPF 的方案,对比基于ghOSt 的方案。用户态调度解决方案Global SchedghOStPlugsched龙蜥社区合作伙伴真实案例 内核开销优化Cgroup 数量较多时,CPU资源开销较大。AMD 256c 大规格机型上整机浪费更严重Load Tracking优化移植上游两个优化补丁,解决load decay 时重复遍历计算空载cgroup的问题。通过热升级:在很短时间内上线优化了性能,每个HT节省5%的CPU。通过验证后,该优化已经合
9、入龙蜥内核主线。真实案例 其它Remove Bandwidth Control删除CFS的限流功能,验证Plugsched删除大量代码的能力Tiny SchedulerFIFO算法的调度器,验证Plugsched只保留调度器功能最小集的能力测试所用优化和bugfix列表:aa93cd53bc1b91、11f10e5420f6ce、45da7a2b0af8fa、b9c88f75226838经各种特性、修复的验证,Plugsched可支持从小到大各种修改会议流程类型描述修改量特性Core Scheduling3,416 LOC(19 file)特性Delete CFS Bandwidth Cont
10、rol1,258 LOC(1 file)特性Group Identity2,592 LOC(7 file)特性ghOSt10,955 LOC(10 file)新调度器Tiny Scheduler3,845 LOC(10 file)删除为主上游补丁Optimizations&Bugfixes9 24 LOC(1 file each)真实案例 代码量系统设计:总览预处理阶段收集调度器子系统信息,决定模块边界,生成模块代码。开发阶段修改代码,在目录里研发新的调度器。部署阶段安装包,模块寻找安全的时机替换调度器。系统设计 调度器模块化定义函数*接口函数*(Finterface)*内部函数*(Finte
11、rnal)*外部函数*(Fexternal)数据收集信息GCC 插件收集函数和变量属性,调用关系等边界分析Fmod=Finterface FinternalFexternal Finterface Finternal代码提取拷贝的代码:Dinternal(Private),Fmod不拷贝代码:Dinternal(Shared),Dexternal,FexternalPlugsched 术语模块化:一个预处理过程,把内核代码,经过一系列转换,自动生成另一份代码,这份代码可以编译成一个内核模块。接口函数、内部函数、外部函数:Plugsched对函数的逻辑分类,决定哪些函数属于模块,哪些函数需要重定
12、向。系统设计-总览预处理阶段收集调度器子系统信息,决定模块边界,生成模块代码。开发阶段修改代码,在目录里研发新的调度器。部署阶段安装包,模块寻找安全的时机替换调度器。系统设计 栈安全检查栈安全检查所有线程的函数调用路径上没有出现被替换的函数检查点-Stop-the-machine停止所有CPU的执行(注意不是freeze)停止之后,让指定CPU执行handler算法优化线程切分二分匹配函数系统设计 函数重定向传统方案替换所有修改了的函数,专门禁止替换调度器相关函数Livepatch运行时重映射另一个虚拟地址到同一物理地址有 TLB flush的额外开销Kpatch用ftrace子系统hook原
13、函数,劫持到新函数开销无法忽略,尤其当热函数数量增加到子系统规模Ksplice对比打补丁前后的object,识别修改的函数Plugsched 方案只替换接口函数(Finterface)wp flag=0(CR0 register)关闭 page protection mode修改函数的prologue为jmp指令wp flag=1(CR0 register)打开 page protection mode利用上下文切换进行核间同步系统设计 数据升级前人工作对象替换/影子数据结构*状态重建*升级前后线程相关数据结构(比如 task_struct)布局是不可变的。通过预留保留字段,来支持添加新的结构
14、体字段。使用*状态迁移函数*来迁移所有进程私有的数据。调度器状态(比如 nr_running,vruntime)自动得到更新。Plugsched 术语状态重建:一个热升级过程,让调度器数据从旧的调度器中迁移到新的调度器状态迁移函数:上游内核里原有的一对函数,分别负责清空状态和恢复。对调度器而言,具体指线程入队/出队函数。方案验证-环境架构调度器模块化预处理脚本(Python in 2K LOC)GCC Plugin、计算脚本热升级基础代码(C in 6K LOC)栈安全检查,函数重定向,状态重建测试环境阿里云 ECS 裸金属实例Dual-socket 48-core CPUs(Intel Xe
15、on(R)Platinum 8163 CPU 2.50GHz)32MB L3 cache192 GB memory spaceKernel 4.19.91方案验证 总体性能细分性能并行化后,栈安全检查时间减少14%/19%,状态重建时间减少38%/45%调度器补丁测试性能7种不同的调度器补丁,测试显示停机时间介于2.1/1.8ms 2.6/2.5ms时间区别主要在Data Rebuild上小补丁删除流控Group Identity Tiny Scheduler方案验证 性能对比kpatchKpatch:广泛应用于业界,适合用于对比比Kpatch停机时间短 24%/26%比Kpatch性能高 1
16、2.0/13.2 倍方案验证 不同的工作集环境两类真实应用:Redis(key-value stores);Nginx(web service)三类通用benchmark:sysbench,hackbench,lookbusyNginx:4ms内性能损失最多36%,4ms后性能恢复正常Benchmark:100%CPU极限压力下,业务停机时机最多比空载时高61%/51%方案验证 扩展性随着 CPU 核心数量增加数据重建时间:当CPU数量从1到6,时间从1287s/1070s 下降到 282s/217s栈安全检查时间:当CPU数量从1到24,时间下降了85%/83%总时间:CPU数量超过6后,总
17、时间稳定在180s 280s随着线程数量增加栈安全检查时间:随着线程数从1000起指数增加,时间几乎没有任何上升(并行化后的算法)数据重建时间:只跟R状态线程数量相关,且随着线程数量上升,时间几乎没有任何上升(图略)方案验证 部署超过 4000台大规格服务器部署 Plugsched 输出的调度器包金融场景、云原生场景、混部场景、用户态调度场景平稳运行,没有出现故障最多 1%的云服务器停机时间较长多家大厂在基于 Plugsched 做调度器研发,或使用Plugsched 输出的调度器包。结论&未来创新:子系统级热升级、子系统模块化、状态重建移植性:3.10/4.18/4.19/5.10;AArc
18、h64/x86-64延伸Plugbpf-Production(请期待 5 月 GOTC 23 演讲)Plugxxx-ResearchingPlugsched v1.2 已发布https:/ 家正在使用 Plugsched SDK 及衍生技术。继续推广。用户体验:v1.3 规划提升用户体验,丰富案例、用例和文档,三月底发布。技术探索:更简单的热升级workflow,kernels 之间一键移植调度器。FAQPlugsched vs 用户态调度协同:二者可以协同创造更大价值用户群体:kernel dev/other dev开销:NearZero/Low High高级特性:/x(yet)复用CFS技术:/xPlugsched vs Kpatch子系统级别/函数级别替换少量接口函数(low overhead)/替换所有函数(high overhead)可以替换调度器函数/不能替换调度器函数调度器状态重建/N/APlugxxx模块化:任意子系统冷升级/热升级:任意子系统/快速路径子系统价值场景:定制优化/快速演进/历史包袱/维护成本/存量内核/紧急需求谢 谢Plugsched 主页