From 3881e9ba2808b3636e405a749cd1da03102a5d4d Mon Sep 17 00:00:00 2001 From: Cheng Jian Date: Wed, 21 Apr 2021 21:04:09 +0800 Subject: [PATCH] description: livepatch --- study/kernel/00-DESCRIPTION/LIVE_PATCH.md | 270 ++++++++++++++++-- study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md | 31 +- study/kernel/00-DESCRIPTION/OPEN_SOURCE.md | 2 + study/kernel/00-DESCRIPTION/README.md | 0 study/kernel/00-DESCRIPTION/SCHEDULER.md | 33 ++- study/kernel/00-DESCRIPTION/TEMPLATE.md | 0 .../04-buddy/04-alloc_page/README.md | 8 +- 7 files changed, 311 insertions(+), 33 deletions(-) mode change 100755 => 100644 study/kernel/00-DESCRIPTION/LIVE_PATCH.md mode change 100755 => 100644 study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md mode change 100755 => 100644 study/kernel/00-DESCRIPTION/README.md mode change 100755 => 100644 study/kernel/00-DESCRIPTION/SCHEDULER.md mode change 100755 => 100644 study/kernel/00-DESCRIPTION/TEMPLATE.md diff --git a/study/kernel/00-DESCRIPTION/LIVE_PATCH.md b/study/kernel/00-DESCRIPTION/LIVE_PATCH.md old mode 100755 new mode 100644 index 1a4c84f..36993b7 --- a/study/kernel/00-DESCRIPTION/LIVE_PATCH.md +++ b/study/kernel/00-DESCRIPTION/LIVE_PATCH.md @@ -14,11 +14,130 @@ **-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* 正文 -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*** +https://ruby-china.org/topics/20680 +https://www.open-open.com/news/view/1d7445f +https://www.infoworld.com/article/2851028/four-ways-linux-is-headed-for-no-downtime-kernel-patching.html -# 1 热补丁实现方案 +# 1 热补丁的历史 ------- -## 1.1 热补丁方案需要解决的问题 +第 1 节内容参照 [History of Linux Kernel Live Patching](https://www.howtoforge.com/history-of-linux-kernel-live-patching) + + + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2008/12/22 | Jeff Arnold | [Ksplice: Rebootless kernel updates](https://lore.kernel.org/patchwork/cover/137199) | KSplice 的实现方案 | v1 ☐ | [PatchWork RFC v3](https://lore.kernel.org/patchwork/cover/135799)
*-*-*-*-*-*-*-*
[PatchWork v1](https://lore.kernel.org/patchwork/cover/137199) | +| 2014/04/30 | Jiri Slaby | [kGraft](https://lore.kernel.org/patchwork/cover/460811) | SUSE 的 Kgraft 方案 | RFC v1 ☐ | [PatchWork RFC](https://lore.kernel.org/patchwork/cover/460811), [LWN](https://lwn.net/Articles/596776) | +| 2014/07/15 | Josh Poimboeuf | [kpatch: dynamic kernel patching](https://lore.kernel.org/patchwork/cover/482999) | Redhat 的实现方案 | v1 ☐ | [PatchWork RFC](https://lore.kernel.org/patchwork/cover/461063)
*-*-*-*-*-*-*-*
[PatchWork v2](https://lore.kernel.org/patchwork/cover/482999) | +| 2014/12/16 | Seth Jennings | [Kernel Live Patching](https://lore.kernel.org/patchwork/cover/527257) | 内核热补丁的基础框架 | v7 ☑ 4.0-rc1 | [PatchWork v7](https://lore.kernel.org/patchwork/cover/527257), [LKML](https://www.lkml.org/lkml/2017/2/13/831)
*-*-*-*-*-*-*-*
[PatchWork v6](https://lore.kernel.org/patchwork/cover/525706/) | + + + +## 1.1 2001–2010: The Patent Trail(专利追溯) +------- + +如果您使用热修补或实时系统更新等关键字浏览专利档案, 您将挖掘许多应用程序和拒绝, 表明更新计算机系统而不停止它的想法并不是什么新鲜事. 追踪从一般到具体的重要日期如下 : + +2001年 : 惠普公司申请了一种动态更新软件以避免丢失硬件功能的方法. +2002年 : 微软加入游戏的方法是在不中断系统的情况下更新系统(Windows). (他们的初始申请因HP的“现有技术”而被驳回. ) +2008年 : Jeff Arnold 宣布推出 Ksplice软件, 用于更新(修补)Linux内核而不会中断(即无需重启1). +2010年 : 微软的专利最终获准上诉. +关于这些的有趣之处在于, 他们共同希望通过软件更新来纠正系统核心软件或硬件中的故障, 而不会影响系统的持续运行并且不会改变硬件. 听起来很熟悉？(线索 : 熔化, 幽灵. ) + +## 1.2 2009年 : KSplice 的诞生 +------- + +Jeff Arnold 是一名麻省理工学院的学生, 正在照看他们的一台[服务器](http://news.mit.edu/2014/bringing-the-world-reboot-less-updates-0124). 它需要一个安全补丁, 但他推迟了它, 因为重新启动会给他的用户带来不便. 在系统更新之前, 它被黑了. 耻辱和(具有讽刺意味的)不便使杰夫在没有延迟而不重新启动系统更新的问题上找到了他的硕士论文的主题. + +这个故事可能是杜撰的, 但它提醒我们, 现场补丁技术的出现不仅仅是为了方便而是为了安全, 它应该受到赞赏. + +Jeff Arnold 与其他三名学生同事一起研究了如何更新 Linux 服务器内核的问题, 没有延迟, 也没有中断系统的进程. 该解决方案采用名为 Ksplice 的软件形式, 其技术基础在2009年的学术论文中提出. 该文章的标题包括"重新启动"这个词, 现在熟悉的"不间断更新"的Linux简写, 但是 2005 年首次由微软创造, 用于 Windows 驱动程序更新. + +image.png +补丁和不打补丁进行了二进制的比较, 找出不同的函数, 源代码patch守护程序提取出不同的函数. 内核源码优化这些不同的单元) + +毕业后, 杰夫和他的麻省理工学院同事创办了 Ksplice Inc., 并于 2009 年 5 月获得麻省理工学院 10 万美元创业大赛奖. 该公司于 2010 年推出了商业服务; 事情进展顺利. + +Ksplice 在替换新内核时, 不需要预先修改;只需要一个diff文件, 列出内核即将接受的修改即可. Ksplice公司免费提供软件, 但技术支持是需要收费的, 这个特性是如此的优秀, 以至于这家新创的公司短时间内就积累了大量的用户. + +参见: + +[Ksplice: kernel patches without reboots](https://lwn.net/Articles/280058) + +[Ksplice and kreplace](https://lwn.net/Articles/308409) + +[Jeff Arnold 的 Ksplice 的补丁提交历史](https://lore.kernel.org/patchwork/project/lkml/list/?series=&submitter=9109&state=*&q=&archive=both&delegate=) + + + +## 1.3 2011-2016 Oracle +------- + + +但在 2011年7月21日 [Oracle 收购了 Ksplice Inc.](https://www.infoworld.com/article/2622437/oracle-buys-ksplice-for-linux--zero-downtime--tech.html), 情况发生了变化. 这项功能被整合到 Oracle 自己的 Linux 发行版本中, 并且只对 Oralcle 自己提供技术更新. + +> 即使 Linux本身就是Red Hat 3 的衍生产品. 尽管有这种传统, 甲骨文仍然停止支持红帽. + + +Ksplice Inc. 在收购前后拥有着大量热补丁技术方面的专利, 而众所周知, Oracle 是一家 [patent troll](https://lwn.net/Articles/584016). + + + +这就导致, 其他 linux 发行版开始寻找替代 Ksplice 的方法, 以避免被 Oracle 收取巨额的专利费. + +[Ksplice](http://ksplice.oracle.com/legacy) + + +## 1.4 百家争鸣 +------- + +在 2011 年和 2014 年之间, SUSE 和 Red Hat 分开工作(并且不了解彼此的目标)来发布他们自己的实时内核更新解决方案, 他们分别在 Kgraft 和 Kpatch 中进行了这些解决方案. + + +### 1.4.1 Kpatch @ Redhat +------- + +2014 年 Red Hat 分享了他们的 Kpatch 代码, 并将其集成为 Red Hat Enterprise Linux 的支持功能. + + +### 1.4.1 Kgraft @ Suse +------- + +[kGraft — live kernel patching from SUSE](https://lwn.net/Articles/584016) + +https://git.kernel.org/pub/scm/linux/kernel/git/jirislaby/kgraft.git/ + +[The initial kGraft submission](https://lwn.net/Articles/596854) + +[kGraft — live kernel patching from SUSE](https://lwn.net/Articles/584016) + + + + +### 1.4.2 KernelCare @ CloudLinux +------- + +由于主要供应商争相成为第一个推出可行的实时补丁解决方案, CloudLinux 是基于 Linux 的网络托管操作系统的主要参与者, 在 3 月成功测试后, 于 2014年5 月推出了KernelCare. + +他们通过在大多数Linux平台上提供最广泛的功能集来为市场感到惊讶, 并在 Linux 内核开发和客户支持方面享有盛誉. 另一个令人震惊的是负担能力, 吸引了网站托管商, 他们发现 KernelCare 的每服务器成本比主要竞争对手的每站点成本更易于管理和扩展. + + +## 1.5 Kgraft + Kpatch 的混合体 Livepatch +------- + +SUSE 和 Red Hat 都尝试将自家的解决方案推向 Linux Mainline, 社区经过激烈的讨论, 最终融合了两家方案的创意形成 livepatch 方案, 合入 v4.0. +随后在并在2016年10月, Canonical 宣布他们正基于 livepatch 推出自己的的商业内核更新服务 Canonical Livepatch服务. + + +## 1.6 总结 +------- + +# 2 热补丁实现方案 +------- + + +## 2.1 热补丁方案需要解决的问题 ------- 1. 函数热替换, 热补丁要完成的最本质的工作, 就是不重启而更新执行的函数, 怎么完成函数的替换. 修改函数的前几条指令, 将指令修改为跳转到新函数的指令可以完成这样的工作. 那有没有其他方法呢 ? @@ -30,19 +149,20 @@ 4. 自动制作热补丁, 我们制作热补丁看到的信息只有修改的补丁, 因此热补丁的制作, 需要程序员对整个编译和链接的过程高度理解, 了解那些符号可能发生了什么样变化, 并能将这些信息组织到热补丁中. 那有没有程序式的工具, 能够自动化完成这些工作, 生成热补丁 KO. -## 1.2 已知热补丁方案 +## 2.2 已知热补丁方案 ------- 在主线内核实现热补丁特性之前, 各个厂商就在社区进行了激烈的讨论, 并各自形成了自己的一套方案. | 方案 | 作者 | 实现 | 一致性模型 | 限制与约束 | |:---:|:----:|:---:|:--------:|:---------:| +| Ksplice | Oracle | [Ksplice: Rebootless kernel updates](https://lore.kernel.org/patchwork/cover/137199) 基于直接跳转方式 | stop_machine | | KGraft | SUSE 的 Jiri Kosina(JK) 和 Jiri Slaby(JS) 合作开发 | 基于 ftrace 方案实现, 采用类 RCU 更新机制 | 只要不会出现同一个 universe 里既调用了旧函数又调用了新函数的情况, 那么就是一致的
对于用户进程, 同一次系统调用是一次 universe
对于内核线程, 每次被唤醒, 判断是否被 stop 条件之后算是一个新的universe
对于中断, 同一次中断处理算是一次 universe | 仅支持 X86_64/s390, 未公开自动化热补丁制作工具 | | Kpatch | REDHAT | 基于 ftrace 方案, 使用 stop_machine + 栈检查来保证一致性 | 使用 stop_machine 机制停下所有 CPU, 然后对所有的进程进行栈检查, 只有在没有任何进程执行被 patched 的函数的情况下, 才认为是安全的 | stop_machine 机制对业务有中断影响, 大概带来 1ms-40ms 的延迟
仅支持 X86_64 | -| kpatch without stop_machine | HITACHI 的 Masami Hiramatsu | 基于 kpatch 方案, 取消了 stop_machine一致性检查 | 不再需要 stop_machine, 引入全局的院子计数器 refcounter, 跟踪目标函数的调用情况, 只有在目标函数没有被执行时(refcounter == 0), 才可以安全的进行替换 | 基于 kpatch
一致性检查存在安全问题 | +| kpatch without stop_machine | HITACHI 的 Masami Hiramatsu | 基于 kpatch 方案, 取消了 stop_machine一致性检查 | 不再需要 stop_machine, 引入全局的院子计数器 refcounter, 跟踪目标函数的调用情况, 只有在目标函数没有被执行时(refcounter == 0), 才可以安全的进行替换 | 基于 kpatch
一致性检查存在安全问题, 参见 [LinuxConNA-kpatch-without-stopmachine_fixed](https://events.static.linuxfound.org/sites/events/files/slides/LinuxConNA-kpatch-without-stopmachine_fixed.pdf), 以及 [kmod/core: Remove stop_machine from kpatch](https://github.com/mhiramathitachi/kpatch/commit/54e86e251ead4fd4db2fcf0f0157b6a41a541d17) | | LIVEPATCH Without Ftrace | HUAWEI | 基于直接跳转实现 livepatch, 不再基于 ftrace, 通过修改函数的前几条指令, 直接跳转到新函数 | 同 kpatch 类似, 采用 stop_machine + 栈检查来保证安全性 | 与 ftrace/kprobe 等同样修改函数指令的特性存在冲突 | -## 1.3 热补丁方案总结 +## 2.3 热补丁方案总结 ------- 总体来看: @@ -54,18 +174,23 @@ | 基于 ftrace 的方案, 通过注册 ftrace, 修改函数的返回地址, ftrace 返回后, 直接跳转到新函数执行 | 跟 ftrace/kprobe 等同样需要修改函数指令的特性不冲突 | 依赖与 ftrace_regs 特性, 支持架构有限
ftrace 方案有性能问题, 虽然使用 x86_64 等架构的 ftrace trampoline 机制可以当前函数只注册了一个 ftrace 的时候直接使用 tracepoline 来优化性能, 但是使用场景受限, 且并不能解决 ftrace 所有的性能问题
基于的特性 ftrace 本身是一个调测特性, 稳定性和安全性都存在一定问题, 商用有一定风险 | | 基于直接跳转的方案, 通过修改函数的前几条指令, 直接跳转到新函数 | 无性能问题 | 跟 ftrace/kprobe 等同样需要修改指令的方案存在冲突
涉及长跳转时, 可能需要改多条指令, 对函数的长度有要求限制
必须有可靠的栈回溯机制, 修改多条指令, 必须要求被 patched 的函数不能正在执行, 否则执行的指令前后不一致, 将出现严重问题 | -2. 一致性模型主要有三种思路 - -| 实现方法 | 优点 | 缺点 | -|:------:|:----:|:---:| -| stop_machine consistency 通过 stop_machine 停住所有核进行一致性检查, 通过栈回溯检查被 patched 函数是否被执行 | 安全可靠, stop_machine 会强制所有核停下原来的工作, 在非抢占式内核, 必然发生进程切换, 则总能找到一个安全的时刻去执行热补丁操作 | stop_machine 会中断原来的业务, 对性能影响较大 | -| per-task consistency 通过标记或者引用技术, 标记出被 patched 的函数都没有执行, 或者进程处于安全上下文的状态 | 不中断原来业务的执行 | 一致性检查并不是完全可信的 | -## 1.4 内核社区的讨论 +## 2.4 内核社区的讨论 ------- -最终经过了激烈的讨论, 大家认为各家的方案都存在一些问题, 社区对于使用哪家的方案也一直犹豫不决. 最终 Redhat 主张先搞一个动态热补丁的通用框架, 基于 ftrace 方案, 完成函数热替换的最基本功能, 不保证安全性, 不使用任何安全性机制, 只通过通用的热补丁制作/注册和使用的接口. 作为一个过渡方案. 而各家 KGraft/Kpatch 基于这个框架完成自己的方案. 一致性模型待后期充分讨论和检验后再做决定. 这个提议的最大依据就是, 大部分的 CVE 补丁即使没有一致性保证, 也可以安全的以动态补丁的方式打上. 因此社区可以先合入这样一个通用的记住方案. 然后接下来在考虑各种一致性方案的问题, 可以选择一种最优的一致性方案, 也可以将各种方案都集成进来, 然后用户根据自己 patch 的特点, 选择不同的一致性模型. 这个提议得到了大多数人的支持, 并由 Redhat 的 Seth Jennings 负责实现这个通用的框架. +最终经过了激烈的讨论, 大家认为各家的方案都存在一些问题, 社区对于使用哪家的方案也一直犹豫不决 + +最终 Redhat 主张先搞一个动态热补丁的通用框架, 基于 ftrace 方案, 完成函数热替换的最基本功能, 不保证安全性, 不使用任何安全性机制, 只通过通用的热补丁制作/注册和使用的接口. 作为一个过渡方案. 而各家 KGraft/Kpatch 基于这个框架完成自己的方案. 一致性模型待后期充分讨论和检验后再做决定. 参见 [Re: [PATCH 0/2] Kernel Live Patching](https://lkml.org/lkml/2014/11/7/306). 这个过程分为如下几个步骤: + +1. 实现一套通用的核心框架, 这三种方法都可以使用(manual、kpatch generator、kGraft generator). + +2. 添加一致性模型(例如 kpatch stop_machine, kGraft per task consistency, Masami's per task ref-count). + +3. 添加组合补丁模块生成工具. + + +这个提议的最大依据就是, 大部分的 CVE 补丁即使没有一致性保证, 也可以安全的以动态补丁的方式打上. 因此社区可以先合入这样一个通用的基础方案. 然后接下来在考虑各种一致性方案的问题, 可以选择一种最优的一致性方案, 也可以将各种方案都集成进来, 然后用户根据自己 patch 的特点, 选择不同的一致性模型. 这个提议得到了大多数人的支持, 并由 Redhat 的 Seth Jennings 负责实现这个通用的框架. | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:--:|:----:|:---------:|:----:| @@ -76,14 +201,111 @@ # 3 一致性模型 consistency model ------- -一致性模型是非常复杂的, 在第一版的 LIVE_PATCH 支持的时候, 邮件列表中分析了几种一致性模型, 但是却没有结论, 参见 [`Re: [PATCH 0/2] Kernel Live Patching`](https://lkml.org/lkml/2014/11/7/354). + +一致性模型主要有三种思路 + +| 实现方法 | 优点 | 缺点 | +|:------:|:----:|:---:| +| stop_machine consistency 通过 stop_machine 停住所有核进行一致性检查, 通过栈回溯检查被 patched 函数是否被执行 | 安全可靠, stop_machine 会强制所有核停下原来的工作, 在非抢占式内核, 必然发生进程切换, 则总能找到一个安全的时刻去执行热补丁操作 | stop_machine 会中断原来的业务, 对性能影响较大 | +| per-task consistency 通过标记或者引用技术, 标记出被 patched 的函数都没有执行, 或者进程处于安全上下文的状态 | 不中断原来业务的执行 | 一致性检查并不是完全可信的 | + + +## 3.1 per-task consitency +------- + + +## 3.2 stop_machine consistency +------- + + +## 3.3 per task ref counting +------- + + + +## 3.2 关于一致性模型的探讨 +------ + + +### 3.2.1 per-task VS stop_machine +------- + +kgraft 的 per-task consistency 和 Kpatch 的 stop_machine consistency 是两种截然不同的一致性模型, 可以参照 Kpatch 的补丁的 [changelog](https://lore.kernel.org/patchwork/cover/482999). + + +### 3.2.2 consistency model 总结 +------- + +一致性模型是非常复杂的, 在第一版的 LIVE_PATCH 开发的时候, 内核开发者们就一致性mixing进行了激烈的讨论. + +最初开发者们建议大家基于 livepatch 的核心框架, 把目前所有的一致性模型都实现了, 然后供用户根据场景自己去选择. 但是随着讨论的不断深入, 邮件列表中分析了几种一致性模型, 参见 [`Re: [PATCH 0/2] Kernel Live Patching`](https://lkml.org/lkml/2014/11/7/354) 或者 [`[PATCH 0/2] Kernel Live Patching`](https://lore.kernel.org/patchwork/cover/514589/). + +在这次讨论中, Vojtech Pavlik 从 Masami Hiramatsu [kpatch without stopmachine](https://events.static.linuxfound.org/sites/events/files/slides/LinuxConNA-kpatch-without-stopmachine_fixed.pdf) 的[实现 kmod/core: Remove stop_machine from kpatch](https://github.com/mhiramathitachi/kpatch/commit/54e86e251ead4fd4db2fcf0f0157b6a41a541d17) 中获得了启发, 发现了 per-task 和 stop_machine 两种一致性模型的相通之处. 然后对一致性模型进行了概括. + + +#### 3.2.2.1 一致性模型 +------- + +首先, 对新旧函数的更新时机做了分类, 即执行必须在哪个实体之外才能进行转换, 从最弱到最强: + +| 转换时机 | 描述 | +|:---:|:----:| +| LEAVE_FUNCTION | 执行必须离开一个修补过的函数切换到新的实现 | +| LEAVE_PATCHED_SET | 执行必须离开补丁函数集, 以切换到新的实现 | +| LEAVE_KERNEL | 执行必须离开整个内核切换到新的实现 | + + +然后, 是什么实体发生了转换. 同样, 从最弱到最强: + +| 转换实体 | 描述 | +|:---:|:----:| +| SWITCH_FUNCTION | 切换到新实现是基于每个函数的 | +| SWITCH_THREAD | 切换到新实现是每线程的 | +| SWITCH_KERNEL | 整个内核同时切换到新的实现 | + +最后我们对目前所有的一致性模型进行对号入座. + +| 一致性模型 | 转换时机 | 转换实体 | +| livepatch (null模型) | LEAVE_FUNCTION | SWITCH_FUNCTION | +| kpatch | LEAVE_PATCHED_SET | SWITCH_KERNEL | +| masami-refcounting | LEAVE_PATCHED_SET | SWITCH_KERNEL | +| Ksplice | LEAVE_PATCHED_SET | SWITCH_KERNEL | +| kGraft | LEAVE_KERNEL | SWITCH_THREAD | +| CRIU/kexec | LEAVE_KERNEL | SWITCH_KERNEL | + + +目前公认最安全的模型是 LEAVE_PATCHED_SET 和 SWITCH_KERNEL, 因为它可靠、快速收敛、不需要注释内核线程. 它提供了所需的最严格的一致性. + +通过混合 kGraft 和 masami-refcounting, 可以创建一个一致性引擎, 它几乎可以包含这些属性的任何组合, 以及所有的一致性模型. + + +> PS.: Livepatch 的 NULL 模型实际上并不是最弱的, 因为它仍然保证执行完整完整的函数, 这要感谢 ftrace. 这比直接在内存中重写函数所达到的效果要大得多. +> 这也是为什么 Ksplice 被锁定在一个非常特定的一致性模型上的原因. Ksplice 只能在内核停止并以此为基础构建模型时进行修补, 因此他不得不使用 stop_machine. +> masami-refcounting, kpatch, kGraft, livepatch 因为是基于 ftrace 的, 在一致性模型中在某些方面有了更多的自由. + +后来 Vojtech Pavlik [Re: [PATCH 0/2] Kernel Live Patching](https://lkml.org/lkml/2014/11/8/15) 又提了一些有趣的场景和例子, 用来说明不同一致性模型的影响. + +#### 3.2.2.2 SWITCH_THREAD VS SWITCH_KERNEL +------- + +SWITCH_THREAD 存在一个问题, 就是它允许旧函数可以与新函数同时运行. 因此当补丁改变数据或数据语义时, 它产生了一些严重的头痛(经过评估 CVE 安全补丁中有 10% 是这样的补丁). 在这种模型下, 这使得补丁的安全分析变得更加困难, 因为你需要考虑的场景的排列加倍了. 除了考虑 newfunc/olddata 和 newfunc/newdata 之外, 还必须考虑 oldfunc/olddata 和 oldfunc/newdata. 为了这种场景引入的问题, 它需要把修复补丁拆成两个. 第一个补丁需要修改旧的功能, 以便能够处理新的数据(oldfunc/newdata). 在完全应用了第一个补丁之后(此时不再出现 oldfunc/newdata), 您可以应用第二个补丁, 它可以开始创建新版本的数据(newfunc/newdata). + +另一方面, SWITCH_KERNEL没有这些问题. 它保证了在同一时刻内核全部由 oldfunc 切换到 newfunc, 但是它也不是完美的, 它需要中断内核中的业务来完成更新, 并检查系统中所有进程的堆栈, 确保没有进程正在执行待更新的路径. 因此它不能修补内核中的热点函数和一直在使用的功能. 但在这种情况下, 我们可以在90%的情况下跳过回溯检查. 所以这真的是一种可能. 经过分析大概有 0.2% 的补丁不能用 SWITCH_KERNEL 打补丁. 但即便如此, 我认为我们也可以通过创造性地解决这个问题, 例如使用多个补丁方法. + +Josh Poimboeuf 的观点是 SWITCH_THREAD 引起头痛的概率是10%, 而 SWITCH_KERNEL 引起头痛的概率是 1.8%. 从这个角度上讲就有一个有趣的模型: LEAVE_PATCHED_SET 和 SWITCH_THREAD, 它提供了最少的更改所需的一致性, 函数的调用约定仍然允许语义依赖关系. + +Josh Poimboeuf 从 Masami kpatch without stop_machine 方案中得到灵感, 认为没有必要把所有的一致性模型都实现, 通过混合 kGraft 和 masami-refcounting, 可以创建一个一致性引擎, 它几乎可以包含这些属性的任何组合, 以及所有的一致性模型. + + +## 3.4 hybrid consistency model +------- 在经过漫长的讨论之后, 基于 PER-TASK 的混合一致性模型合入了主线. | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:--:|:----:|:---------:|:-----:| -| 2017/2/13 | Josh Poimboeuf | [livepatch: hybrid consistency model](https://lore.kernel.org/patchwork/cover/760164) | 基于 Kgraft 的PER TASK 的状态检查和基于 Redhat 可靠的栈检查的混合一致性模型 | v4 ☑ 4.12-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/760164), [LKML](https://www.lkml.org/lkml/2017/2/13/831) | +| 2017/2/13 | Josh Poimboeuf | [livepatch: hybrid consistency model](https://lore.kernel.org/patchwork/cover/760164) | 基于 Kgraft 的PER TASK 的状态检查和基于 Redhat 可靠的栈检查的混合一致性模型 | v5 ☑ 4.12-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/760164), [LKML](https://www.lkml.org/lkml/2017/2/13/831) | 这个一致性模型被称为 **混合一致性模型 "hybrid consistency model"**, 因为他融合了 @@ -95,24 +317,24 @@ 将这几种互补的一致性方法结合, 来确定什么时候可以安全地修补任务 -1. 第一个也是最有效的方法是对睡眠任务进行堆栈检查。如果给定任务的堆栈中没有受影响的函数，则该任务将被修补。在大多数情况下，这将在第一次尝试时修补大部分或所有的任务。否则它会周期性地不断尝试。这个选项只有在体系结构有可靠的堆栈时才可用(HAVE_RELIABLE_STACKTRACE)。 +1. 第一个也是最有效的方法是对睡眠任务进行堆栈检查. 如果给定任务的堆栈中没有受影响的函数, 则该任务将被修补. 在大多数情况下, 这将在第一次尝试时修补大部分或所有的任务. 否则它会周期性地不断尝试. 这个选项只有在体系结构有可靠的堆栈时才可用(HAVE_RELIABLE_STACKTRACE). -2. 第二种方法(如果需要的话)是内核退出切换。当任务从系统调用、用户空间IRQ或信号返回到用户空间时，它就被切换。它在以下情况下是有用的: - * a) 修补I/O 绑定的用户任务，这些任务在受影响的函数上处于休眠状态。在这种情况下，您必须发送SIGSTOP和SIGCONT来强制它退出内核并进行修补。 +2. 第二种方法(如果需要的话)是内核退出切换. 当任务从系统调用、用户空间IRQ或信号返回到用户空间时, 它就被切换. 它在以下情况下是有用的: + * a) 修补I/O 绑定的用户任务, 这些任务在受影响的函数上处于休眠状态. 在这种情况下, 您必须发送SIGSTOP和SIGCONT来强制它退出内核并进行修补. - * b) 修补cpu绑定的用户任务。如果任务是高度cpu限制的，那么它将在下次被IRQ中断时得到修补。 + * b) 修补cpu绑定的用户任务. 如果任务是高度cpu限制的, 那么它将在下次被IRQ中断时得到修补. - * c) 在将来，它可以用于为还没有HAVE_RELIABLE_STACKTRACE的架构应用补丁。在这种情况下，您必须向系统上的大多数任务发出信号。然而，这还不支持，因为目前没有办法在没有HAVE_RELIABLE_STACKTRACE的情况下修补线程。 + * c) 在将来, 它可以用于为还没有HAVE_RELIABLE_STACKTRACE的架构应用补丁. 在这种情况下, 您必须向系统上的大多数任务发出信号. 然而, 这还不支持, 因为目前没有办法在没有HAVE_RELIABLE_STACKTRACE的情况下修补线程. -3. 对于空闲任务 "swapper"(IDLE) ，因为它们永远不会退出内核，所以它们在空闲循环中有一个 klp_update_patch_state()调用，允许它们在CPU进入空闲状态之前被修补。 +3. 对于空闲任务 "swapper"(IDLE) , 因为它们永远不会退出内核, 所以它们在空闲循环中有一个 klp_update_patch_state()调用, 允许它们在CPU进入空闲状态之前被修补. -## 3.1 per-task consistency model +### 3.4.1 per-task consistency model ------- 混合一致性模型中使用了 per-task 的一致性模型, 参见 [livepatch: change to a per-task consistency model](https://lore.kernel.org/patchwork/patch/760175). -## 3.2 reliable stacktrace +### 3.4.2 reliable stacktrace ------- 可靠栈检查则进一步对 per-task 的一致性模型做了补充. 他检查函数是否正在运行, [livepatch: change to a per-task consistency model](https://lore.kernel.org/patchwork/patch/760175) @@ -172,6 +394,8 @@ kpatch 的实现一直是根据内核的进展而演进的, 对 JUMP_LABEL 的 ------- + + # 7 Kpatch 自动化工具 ------- diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md old mode 100755 new mode 100644 index 4b6ee6b..3655502 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -313,6 +313,24 @@ Linux 为每个 zone 都设置了独立的 min, low 和 high 三个档位的 wat 整个补丁在测试场景下将外碎片时间减少 94% 以上, 这收益大部分来自于补丁 1-4, 但补丁 5 可以处理罕见的特例, 并为THP分配成功率提供调整系统的选项, 以换取一些档位来控制碎片化. + +### 2.1.1.6 页面窃取 page stealing +------- + + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2015/01/23 | Vlastimil Babka | [page stealing tweaks](https://lore.kernel.org/patchwork/cover/535613) | | v1 ☑ 4.13-rc1 | [PatchWork v1](https://lore.kernel.org/patchwork/cover/535613) | +| 2017/03/07 | Vlastimil Babka | [try to reduce fragmenting fallbacks](https://lore.kernel.org/patchwork/cover/766804) | 修复 [Regression in mobility grouping?](https://lkml.org/lkml/2016/9/28/94) 上报的碎片化问题, 通过修改 fallback 机制和 compaction 机制来减少永久随便化的可能性. 其中 fallback 修改时, 仅尝试从不同 migratetype 的 pageblock 中窃取的页面中挑选最小(但足够)的页面. | v3 ☑ 4.12-rc1 | [PatchWork v6](https://lore.kernel.org/patchwork/cover/766804), [关键 commit 3bc48f96cf11 ("mm, page_alloc: split least stolen page in fallback")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3bc48f96cf11ce8699e419d5e47ae0d456403274) | +| 2017/05/29 | Vlastimil Babka | [mm, page_alloc: fallback to smallest page when not stealing whole pageblock](https://lore.kernel.org/patchwork/cover/793063) | | v1 ☑ 4.13-rc1 | [PatchWork v1](https://lore.kernel.org/patchwork/cover/793063), [commit 7a8f58f39188](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7a8f58f3918869dda0d71b2e9245baedbbe7bc5e) | + +commit fef903efcf0cb9721f3f2da719daec9bbc26f12b +Author: Srivatsa S. Bhat +Date: Wed Sep 11 14:20:35 2013 -0700 + + mm/page_allo.c: restructure free-page stealing code and fix a bug + + ## 2.1.2 内核级别的 malloc 分配器之-对象分配器(小内存分配) ------- @@ -339,6 +357,9 @@ https://lore.kernel.org/patchwork/patch/47616/ https://lore.kernel.org/patchwork/patch/46669/ https://lore.kernel.org/patchwork/patch/46671/ +https://lore.kernel.org/patchwork/cover/408914 + + ### 2.1.2.1 SLAB ------- @@ -432,12 +453,11 @@ SLUB 在解决了上述的问题之上, 提供与 SLAB 完全一样的接口, **3.5(2012年7月发布)** - - | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2007/02/28 | Mel Gorman | [Introduce ZONE_CMA](https://lore.kernel.org/patchwork/cover/778794) | 新增了 ZONE_CMA 区域, 使用新的分区不仅可以有H/W 寻址限制, 还可以有 S/W 限制来保证页面迁移. | v7 ☐ | [PatchWork v7](https://lore.kernel.org/patchwork/cover/778794) | | 2007/02/28 | Mel Gorman | [mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE](https://lore.kernel.org/patchwork/cover/857428) | 新增了 ZONE_CMA 区域, 使用新的分区不仅可以有H/W 寻址限制, 还可以有 S/W 限制来保证页面迁移. | v2 ☐ | [PatchWork v7](https://lore.kernel.org/patchwork/cover/857428) | +| 2015/02/12 | Joonsoo Kim | [mm/compaction: enhance compaction finish condition](https://lore.kernel.org/patchwork/patch/542063) | 同样的, 之前 NULL 指针和错误指针的输出也很混乱, 进行了归一化. | v1 ☑ 4.1-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/542063)
*-*-*-*-*-*-*-*
[关键 commit 2149cdaef6c0](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2149cdaef6c0eb59a9edf3b152027392cd66b41f) | 顾名思义,这是一个分配连续物理内存页面的分配器. 也许你会疑惑伙伴分配器不是也能分配连续物理页面吗? 诚然, 但是一个系统在运行若干时间后, 可能很难再找到一片足够大的连续内存了, 伙伴系统在这种情况下会分配失败. 但连续物理内存的分配需求是刚需: 一些比较低端的 DMA 设备只能访问连续的物理内存; 还有下面会讲的透明大页的支持, 也需要连续的物理内存. @@ -1374,6 +1394,13 @@ SLAB 作为一个相对独立的子模块, 一直有自己完善的调试支持, 相关的文章介绍: [47]. +# 2.15 功耗管理 +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2016/04/15 | Srivatsa S. Bhat | [mm: Memory Power Management](https://lore.kernel.org/patchwork/cover/408914) | 内存的电源管理策略 | v4 ☑ 4.4-rc1 | [PatchWork RFC v4](https://lore.kernel.org/patchwork/cover/408914), [LWN](https://lwn.net/Articles/547439/) | + --- diff --git a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md index 8de0218..1e01df6 100644 --- a/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md +++ b/study/kernel/00-DESCRIPTION/OPEN_SOURCE.md @@ -23,3 +23,5 @@ | 华为| [openeuler](http://gitee.com/openeuler/kernel) | [openeuler](https://openeuler.org/zh) | | 阿里巴巴 | [alikernel](https://github.com/alibaba/alikernel) | [阿里云智能基础软件部-技术博客](https://kernel.taobao.org), [Alibaba Cloud Linux 2 DOC](https://help.aliyun.com/document_detail/154950.html?spm=a2c4g.11186623.3.3.37157594hOc6qA) | | 腾讯 | [TencentOS-kernel](https://github.com/Tencent/TencentOS-kernel) | NA | +| AMAZON | [AmazonLinux](https://github.com/amazonlinux/linux) | +| ORACLE | [linux-uek](https://github.com/oracle/linux-uek) | [linux-kernel-development](https://blogs.oracle.com/linux/linux-kernel-development) | diff --git a/study/kernel/00-DESCRIPTION/README.md b/study/kernel/00-DESCRIPTION/README.md old mode 100755 new mode 100644 diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md old mode 100755 new mode 100644 index b9eddd6..a3d3a22 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -373,7 +373,7 @@ linux 调度器定义了多个调度类, 不同调度类的调度优先级不同 |:----:|:----:|:---:|:----:|:---------:|:----:| | 2010/06/08 | Michael Neuling | [sched: asymmetrical packing for POWER7 SMT4](https://lore.kernel.org/patchwork/cover/202834) | 这个补丁集实现了非对称 SMT 封装(SD_ASYM_PCAKING), 在任务负载小的时候, 将进程都打包在 SMT 域内的某一个 CPU 上, 从而确保在 POWER7 上始终保持良好的性能. 如果没有这个系列, 在 POWER7 上, 任务的性能将有大约 +/-30% 的抖动. | v2 ☐ |[PatchWork RFC](https://lore.kernel.org/patchwork/cover/1408312)) | | 2016/11/01 | Ricardo Neri | [Support Intel® Turbo Boost Max Technology 3.0](https://lore.kernel.org/patchwork/cover/722406) | 支持 Intel 超频 | RFC ☑ 5.9-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/722406) | -| 2021/04/06 | Ricardo Neri | [sched/fair: Fix load balancing of SMT siblings with ASYM_PACKING](https://lore.kernel.org/patchwork/cover/1408312) | 修复 ASYM_PACKING 和 load_balance 的冲突. | v1 ☐ | [PatchWork](https://lore.kernel.org/patchwork/cover/1408312) | +| 2021/04/14 | Ricardo Neri | [sched/fair: Fix load balancing of SMT siblings with ASYM_PACKING](https://lore.kernel.org/patchwork/cover/1408312) | 修复 ASYM_PACKING 和 load_balance 的冲突. | v2 ☐ | [PatchWork v1](https://lore.kernel.org/patchwork/cover/1408312)
*-*-*-*-*-*-*-*
[PatchWork v2](https://lore.kernel.org/patchwork/cover/1413015) | core_scheduling 与 coscheduling @@ -819,11 +819,14 @@ ARM 的 Morten Rasmussen 一直致力于ANDROID 调度器优化的: | 2016/10/14 | Vincent Guittot | [sched: Clean-ups and asymmetric cpu capacity support](https://lore.kernel.org/patchwork/cover/725608) | 调度程序目前在非对称计算能力的系统上没有做太多的工作来提高性能(读ARM big.LITTLE). 本系列主要通过对任务唤醒路径进行一些调整来改善这种情况, 这些调整主要考虑唤醒时的计算容量, 而不仅仅考虑cpu对这些系统是否空闲. 在部分使用的场景中, 这为我们提供了一致的、可能更高的吞吐量. SMP的行为和性能应该是不受影响.
注意这组补丁是分批合入的 | v1 ☑ 4.10-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/725608) | | 2018/03/15 | Morten Rasmussen | [sched/fair: Migrate 'misfit' tasks on asymmetric capacity systems](https://lore.kernel.org/patchwork/cover/933989) | 异构 CPU 上 wakeup 路径倾向于使用 prev CPU | v1 ☑ 4.20-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/933989) | | 2018/12/03 | Quentin Perret | [Energy Aware Scheduling](https://lore.kernel.org/patchwork/cover/1020432) | 能效感知的调度器 EAS | v10 ☑ 5.0-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1020432) | +| 2019/08/22 | Patrick Bellasi | [Add utilization clamping support (CGroups API)](https://lore.kernel.org/patchwork/cover/1118345) | TASK util clamp(Android schedtune 的主线替代方案) | v14 ☑ 5.4-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1118345) | | 2020/02/06 | Vincent Guittot | [sched/fair: Capacity aware wakeup rework](https://lore.kernel.org/patchwork/cover/1190300) | 异构 CPU 上 wakeup 路径优化 | v4 ☑ 5.7-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1190300) | | 2020/05/20 | Dietmar Eggemann | [Capacity awareness for SCHED_DEADLINE](https://lore.kernel.org/patchwork/cover/1245028) | DEADLINE 感知 Capacity | v3 ☐ 5.9-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1245028) | | 2020/12/19 | Vincent Guittot | [sched/fair: prefer prev cpu in asymmetric wakeup path](https://lore.kernel.org/patchwork/cover/1329119) | 异构 CPU 上 wakeup 路径倾向于使用 prev CPU | v1 ☑ 5.10-rc4 | [PatchWork](https://lore.kernel.org/patchwork/cover/1308748) | | 2021/03/11 | Valentin Schneider | [sched/fair: misfit task load-balance tweaks](https://lore.kernel.org/patchwork/cover/1393531) | 优化 misfit task 的一些逻辑 | v3 ☐ 5.10-rc4 | [PatchWork](https://lore.kernel.org/patchwork/cover/1393531) | -| 2019/08/22 | Patrick Bellasi | [Add utilization clamping support (CGroups API)](https://lore.kernel.org/patchwork/cover/1118345) | TASK util clamp(Android schedtune 的主线替代方案) | v14 ☑ 5.4-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1118345) | +| 2021/04/07 | Valentin Schneider | [sched/fair: load-balance vs capacity margins](https://lore.kernel.org/patchwork/cover/1409479) | misfit task load-balance tweaks 的补丁被拆分重构, 这个是 Part 1 | v3 ☐ 5.10-rc4 | [PatchWork](https://lore.kernel.org/patchwork/cover/1409479) | +| 2021/04/16 | Valentin Schneider | [sched/fair: (The return of) misfit task load-balance tweaks](https://lore.kernel.org/patchwork/cover/1414181) | misfit task load-balance tweaks 的补丁被拆分重构, 这个是 Part 2 | v1 ☐ 5.10-rc4 | [PatchWork](https://lore.kernel.org/patchwork/cover/1414181) | +| 2021/04/16 | Valentin Schneider | [Rework CPU capacity asymmetry detection](https://lore.kernel.org/patchwork/cover/1414557) | 优化 misfit task 的一些逻辑 | v3 ☐ 5.10-rc4 | [PatchWork](https://lore.kernel.org/patchwork/cover/1414557) | ## 1.7.5 基于调度器的调频 @@ -882,6 +885,11 @@ CPUFreq 驱动是处理和平台相关的逻辑, Governor 中实现了具体的 ------- +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:---:|:----------:|:----:| +| 2021/01/22 | Joel Fernandes (Google)" | [sched/fair: Rate limit calls to update_blocked_averages() for NOHZ](https://lore.kernel.org/patchwork/patch/1369598) | 在运行ChromeOS Linux kernel v5.4 的 octacore ARM64 设备上, 发现有很多对 update_blocked_average() 的调用, 导致调度的开销增大, 造成 newilde_balance 有时需要最多500微秒. 我在周期平衡器中也看到了这一点. 将 update_blocked_average() 调用速率限制为每秒 20 次 | v1 ☐ | [PatchWork](https://lore.kernel.org/patchwork/cover/1369598) | + + ## 1.8.3 task/CPU 隔离 ------- @@ -893,6 +901,7 @@ CPUFreq 驱动是处理和平台相关的逻辑, Governor 中实现了具体的 | 2020/11/23 | Alex Belits | [support "task_isolation" mode](https://lwn.net/Articles/816298) | NO_HZ_FULL 的进一步优化, 进一步降低 tick 等对隔离核的影响 | v5 ☐ | [2016 Chris Metcalf v16](https://lore.kernel.org/patchwork/cover/847460)
*-*-*-*-*-*-*-*
Alex Belits 2020 [LWN](https://lwn.net/Articles/813804), [PatchWork](https://lore.kernel.org/patchwork/cover/1344134), [lkml](https://lkml.org/lkml/2020/11/23/1380) | | 2020/12/27 | Frederic Weisbecker | [context_tracking: Flatter archs not using exception_enter/exit() v2](https://lore.kernel.org/patchwork/patch/1327311) | 为了能够在运行时打开/关闭 nohz_full 所做的准备, 需要 arch 放弃在任务堆栈上保存上下文跟踪状态, 因为这将迫使上下文跟踪在整个系统范围内运行, 即使是在没有启用 nohz_full 的 CPU 上 | v2 ☑ 5.11-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1327311) | + * 隔离 IRQD_AFFINITY_MANAGED 的中断 设置了 IRQD_AFFINITY_MANAGED 的中断, 其亲和性将由内核自动管理, 用户无法通过 `/proc/irq/*` 接口改变中断的亲和性, 这会导致亲和性同时包含隔离核和非隔离核, @@ -1006,11 +1015,23 @@ Linux 内核会将大量(并且在不断增加中)工作放置在内核线程中 后来主线上 Dexuan Cui 报 Migrate Disable 合入后引入了问题, [5.10: sched_cpu_dying() hits BUG_ON during hibernation: kernel BUG at kernel/sched/core.c:7596!](https://lkml.org/lkml/2020/12/22/141). Valentin Schneider 怀疑是有些 kworker 线程在 CPU 下线后又选到了下线核上运行, 因此建议去测试这组补丁 [workqueue: break affinity initiatively](https://lkml.org/lkml/2020/12/18/406). Dexuan Cui 测试以后可以解决这个问题, 但是会有其他 WARN. Peter Zijlstra 的 解决方案如下 [sched: Fix hot-unplug regression](https://lore.kernel.org/patchwork/cover/1368710). -# 1.9 调试信息 +# 1.9 CPU HOTPLUG 中的调度处理 ------- -## 1.9.1 统计信息 + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2016/03/10 | Tejun Heo | [sched: define and use CPU_PRI_* enums for cpu notifier priorities](https://lore.kernel.org/patchwork/cover/201980) | 重构 migration_call 的 通知方式 | v1 ☑ 2.6.36-rc1 | 注意补丁有 UPATE, [UPDATE](https://lore.kernel.org/patchwork/cover/202907) | +| 2016/03/10 | Thomas Gleixner | [sched: Migrate disable support](https://lore.kernel.org/patchwork/cover/657710) | 将 CPU 下线时 MIGRATE 的操作放到了 sched_cpu_dying() 中进行 | v1 ☑ 4.7-rc1 | [2020/09/11 preparations](https://lore.kernel.org/patchwork/cover/657710) | +| 2020/10/23 | Peter Zijlstra | [sched: Migrate disable support](https://lore.kernel.org/patchwork/cover/1323936) | 在启用 PREEMPT_RT 的内核上, 包括spin/rw锁持有部分在内的大部分代码都是可抢占的, 也使得任务可以迁移. 这违反了每个CPU的约束. 因此, PREEMPT_RT 需要一种独立于抢占的机制来控制迁移. 此特性移除了 sched_cpu_dying(), 改为 balance_push 来完成这个操作 | v4 ☑ 5.11-rc1 | [2020/09/11 preparations](https://lore.kernel.org/patchwork/cover/1304210)
*-*-*-*-*-*-*-*
[2020/09/21 v1 PatchWork](https://lore.kernel.org/patchwork/cover/1309702)
*-*-*-*-*-*-*-*
[2020/10/23 v4 PatchWork](https://lore.kernel.org/patchwork/cover/1323936) | + + +# 1.10 调试信息 +------- + + +## 1.10.1 统计信息 ------- 阿里的王贇 [sched/numa: introduce numa locality](https://lore.kernel.org/patchwork/cover/1190383) 提供了 per-cgroup 的 NUMASTAT 功能, 发到了 2020/02/07 v8, 但是最终还是没能合入主线. @@ -1021,7 +1042,7 @@ Linux 内核会将大量(并且在不断增加中)工作放置在内核线程中 | 2021/03/27 | Yafang Shao | [sched: support schedstats for RT sched class](https://lore.kernel.org/patchwork/cover/1403138) | 我们希望使用 schedstats 工具测量生产环境中 RT 任务的延迟, 但目前只支持公平调度类的 schedstats. 将 sched_statistics 修改为独立于 task_struct 或 task_group 的调度统计数据, 从而完成了 RT 的 schedstats 支持 | [PatchWork v2](https://lore.kernel.org/patchwork/cover/1403138) | -## 1.9.2 tracepoint +## 1.10.2 tracepoint ------- [`tracepoints-helpers`](https://github.com/auldp/tracepoints-helpers.git) @@ -1036,7 +1057,7 @@ Linux 内核会将大量(并且在不断增加中)工作放置在内核线程中 | 2020/06/19 | | [Sched: Add a tracepoint to track rq->nr_running](https://lore.kernel.org/patchwork/patch/1258690) | 增加 nr_running 的跟踪点 | v1 ☑ 5.9-rc1 | [PatchWork](https://lore.kernel.org/patchwork/patch/1258690)
*-*-*-*-*-*-*-*
[FixPatch](https://lore.kernel.org/patchwork/patch/1284621) | | 2020/08/28 | | [sched/debug: Add new tracepoint to track cpu_capacity](https://lore.kernel.org/patchwork/patch/1296761) | 增加 cpu_capacity 的跟踪点 | v1 ☐ | [PatchWork](https://lore.kernel.org/patchwork/cover/1296761) | -## 1.9.3 debug 接口 +## 1.10.3 debug 接口 ------- diff --git a/study/kernel/00-DESCRIPTION/TEMPLATE.md b/study/kernel/00-DESCRIPTION/TEMPLATE.md old mode 100755 new mode 100644 diff --git a/study/kernel/02-memory/04-buddy/04-alloc_page/README.md b/study/kernel/02-memory/04-buddy/04-alloc_page/README.md index b3b4bb2..138af25 100755 --- a/study/kernel/02-memory/04-buddy/04-alloc_page/README.md +++ b/study/kernel/02-memory/04-buddy/04-alloc_page/README.md @@ -986,7 +986,7 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order, ``` -![`__rmqueue_fallback` 流程](./__rmqueue_fallback.png) +![`__rmqueue_fallback` 流程](./__rmqueue_smallest.png) 1. 从期望申请的 order 空闲页面中开始申请目标 MIGRATE_TYPE 类型的页面, 如果没有找到, 则继续从更大 order 的空闲页面中申请, 直到 MAX_ORDER 为止; @@ -1000,6 +1000,9 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order, ### 3.4.4 `__rmqueue_fallback` ------- +> The `__rmqueue_fallback()` function is called when there's no free page of requested migratetype, and we need to steal from a different one. + + 如果前面的流程都分配失败了, 那么说明当前 ZONG 区域指定 MIGRATE_TYPE 中没有足够的空闲页来完成本次分配了. 那么内核将通过 [`__rmqueue_fallback`](https://elixir.bootlin.com/linux/v5.10/source/mm/page_alloc.c#L2759) 尝试从当前 ZONE 的其他 MIGRATE_TYPE 的空闲链表中挪用内存. @@ -1053,6 +1056,8 @@ static int fallbacks[MIGRATE_TYPES][3] = { find_smallest 流程其实是内核 4.13 合入的优化, 那么我们先来看这个优化合入之前的版本, 接着再结合优化来看, 当前这个版本的实现. +[7a8f58f39188 ("mm, page_alloc: fallback to smallest page when not stealing whole pageblock")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7a8f58f3918869dda0d71b2e9245baedbbe7bc5e), 4.13-rc1 合入 + 我们先来看 v4.12 时 [`__rmqueue_fallback`](https://elixir.bootlin.com/linux/v4.12/source/mm/page_alloc.c#L2599) 的实现 ```cpp @@ -1173,4 +1178,3 @@ static void steal_suitable_fallback(struct zone *zone, struct page *page, unsigned int alloc_flags, int start_type, bool whole_block) ``` -[7a8f58f39188 ("mm, page_alloc: fallback to smallest page when not stealing whole pageblock")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7a8f58f3918869dda0d71b2e9245baedbbe7bc5e), 4.13-rc1 合入 \ No newline at end of file