吴一昊-调度器热升级 - OS2ATC.pdf

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