diff --git a/study/kernel/00-DESCRIPTION/BPF.md b/study/kernel/00-DESCRIPTION/BPF.md index 7c15b01..fa4fe7e 100644 --- a/study/kernel/00-DESCRIPTION/BPF.md +++ b/study/kernel/00-DESCRIPTION/BPF.md @@ -161,6 +161,7 @@ raw_tracepoint 相比 tracepoint | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2018/08/26 | Kumar Kartikeya Dwivedi | [Implement file local storage](https://patchwork.kernel.org/project/netdevbpf/cover/20210826133913.627361-1-memxor@gmail.com/) | 本系列实现了 eBPF LSM 程序的文件本地存储映射. 这允许将映射中数据的生存期与打开的文件描述联系起来. 与其他本地存储映射类型一样, 数据的生存期与结构文件实例相关联. 主要用途是:
1. 用于将与 eBPF 程序中打开的文件(而非 fd)关联的数据绑定在一起, 以便在文件消失时释放数据(例如, 检查点checkpoint/恢复用例restore usecase).
2. 使用eBPF LSM 在用户空间中实现[辣椒(Capsicum)风格的功能沙盒](https://www.usenix.org/legacy/event/sec10/tech/full_papers/Watson), 使用此机制在文件级别强制执行权限. | v2 ☐ | [PatchWork bpf-next,v2,0/5](https://patchwork.kernel.org/project/netdevbpf/cover/20210826133913.627361-1-memxor@gmail.com) | +| 2022/04/08 | Song Liu | [vmalloc: bpf: introduce VM_ALLOW_HUGE_VMAP](https://patchwork.kernel.org/project/linux-mm/cover/20220408223443.3303509-1-song@kernel.org/) | 630581 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20220408223443.3303509-1-song@kernel.org) | diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index 190d68d..4d5f169 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -3498,6 +3498,7 @@ Facebook 指出他们也面临过同样的问题, 所有的 workload 都需要 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/08/09 | SeongJae Park | [mm: introduce process_mrelease system call](https://lore.kernel.org/patchwork/patch/1474134) | 引入 process_mrelease() 加速进程的清理, 以更快地释放被杀死的进程的内存.
我们经常希望能杀死不必要的进程, 为更重要的进程释放内存. 例如 Facebook 的 OOM killer 守护程序 oomd 和 Android的低内存killer守护程序lmkd. 对于这样的系统组件, 能够快速有效地释放内存非常. 但是不幸的是, 当一个进程接收到 SIGKILL 信号的时候并不一定能及时释放自己的内存, 这可能会受到很多因素的影响, 譬如进程的状态(它可能是处于 uninterruptible sleep 态)、正在运行进程的的 core 的 OPP 级别等. 而通过调用这个新的 process_mrelease() 系统调用, 它会在调用者的上下文中释放被杀死的进程的内存. 这种方式下, 内存的释放更可控, 因为它直接在当前 CPU 上运行, 只取决于调用者任务的优先级大小. 释放内存的工作量也将由调用方承担. | v9 ☑ [5.15-rc1](https://kernelnewbies.org/LinuxChanges#Linux_5.15.Introduce_process_mrelease.282.29_system_call) | [PatchWork v9,1/2](https://lore.kernel.org/patchwork/patch/1474134) | +| 2022/04/07 | Yosry Ahmed | [memcg: introduce per-memcg proactive reclaim](https://patchwork.kernel.org/project/linux-mm/cover/20220407224244.1374102-1-yosryahmed@google.com/) | 630204 | v2 ☐☑ | [LORE v2,0/4](https://lore.kernel.org/r/20220407224244.1374102-1-yosryahmed@google.com) | @@ -5129,7 +5130,7 @@ zone->lru_锁是一个竞争激烈的锁, 因此 2012 年左右 Konstantin Khleb | 2017/05/30 | Johannes Weiner | [mm: per-lruvec slab stats](https://lore.kernel.org/patchwork/patch/793422) | Josef 正在研究一种平衡 slab 缓存和 page cache 的新方法. 为此, 他需要 lruvec 级别的 slab 缓存统计信息. 这些补丁通过添加基础设施来实现这一点, 该基础设施允许每个 lruvec 更新和读取通用 VM 统计项, 然后将一些现有VM记帐站点(包括slab记帐站点)切换到这个新的 cgroup 感知 API. | v1 ☑ 4.13-rc1 | [PatchWork 0/6](https://lore.kernel.org/patchwork/patch/793422) | | 2021/02/17 | Yang Shi | [Make shrinker's nr_deferred memcg aware](https://lore.kernel.org/patchwork/patch/1393744) | 最近, 在一些 vfs 元数据繁重的工作负载上看到了大量的 one-off slab drop, 造成收缩器了大量累积的 nr_deferred 对象.
这个是由多种原因导致的.
这组补丁集使 nr_deferred 变成 per-memcg 来解决问题. | v10 ☑ 5.13-rc1 | [PatchWork v10,00/13](https://patchwork.kernel.org/project/linux-mm/cover/20210217001322.2226796-1-shy828301@gmail.com) | | 2021/10/19 | Huangzhaoyang | [mm: skip current when memcg reclaim](https://patchwork.kernel.org/project/linux-mm/patch/1634628576-27448-1-git-send-email-huangzhaoyang@gmail.com) | NA | v2 ☐ | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/1634278529-16983-1-git-send-email-huangzhaoyang@gmail.com)
*-*-*-*-*-*-*-*
[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/1634628576-27448-1-git-send-email-huangzhaoyang@gmail.com) | -| 2022/03/31 | Yosry Ahmed | [memcg: introduce per-memcg reclaim interface](https://patchwork.kernel.org/project/linux-mm/patch/20220331084151.2600229-1-yosryahmed@google.com) | 用户空间主动回收器可以持续探测 MEMCG 以回收少量内存. 随着 LRU 不断排序, 这将提供更准确和最新的工作集估计, 并可能提供更具确定性的内存过度使用行为. 内存超分配控制器可以对正在运行的应用程序不断变化的行为提供更主动的响应, 而不是被动响应. 在这种情况下, 用户空间回收器的目的不是完全替代 KSWAPD 或直接回收, 而是主动识别内存节约机会, 回收策略设置的一些冷页, 以释放内存, 用于要求更高的作业或安排新作业.
谷歌数据中心使用了用户空间主动回收器. 此外, Meta 的[论文 TMO](https://dl.acm.org/doi/pdf/10.1145/3503222.3507731) 最近引用了一个非常类似的特性, 用于用户空间主动回收. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220331084151.2600229-1-yosryahmed@google.com) | +| 2022/04/07 | Yosry Ahmed | [[memcg: introduce per-memcg proactive reclaim](https://patchwork.kernel.org/project/linux-mm/cover/20220407224244.1374102-1-yosryahmed@google.com) | 早期叫 [memcg: introduce per-memcg proactive reclaim](https://patchwork.kernel.org/project/linux-mm/cover/20220407224244.1374102-1-yosryahmed@google.com), 用户空间主动回收器可以持续探测 MEMCG 以回收少量内存. 随着 LRU 不断排序, 这将提供更准确和最新的工作集估计, 并可能提供更具确定性的内存过度使用行为. 内存超分配控制器可以对正在运行的应用程序不断变化的行为提供更主动的响应, 而不是被动响应. 在这种情况下, 用户空间回收器的目的不是完全替代 KSWAPD 或直接回收, 而是主动识别内存节约机会, 回收策略设置的一些冷页, 以释放内存, 用于要求更高的作业或安排新作业.
谷歌数据中心使用了用户空间主动回收器. 此外, Meta 的[论文 TMO](https://dl.acm.org/doi/pdf/10.1145/3503222.3507731) 最近引用了一个非常类似的特性, 用于用户空间主动回收. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220331084151.2600229-1-yosryahmed@google.com)
*-*-*-*-*-*-*-*
[LORE v2,0/4](https://lore.kernel.org/r/20220407224244.1374102-1-yosryahmed@google.com)
*-*-*-*-*-*-*-*
[LORE v3,0/4](https://lore.kernel.org/r/20220408045743.1432968-1-yosryahmed@google.com) | @@ -5515,10 +5516,10 @@ Intel 的吴峰光 [PMEM NUMA node and hotness accounting/migration](https://lor |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/04/15 | Tim Chen | [Manage the top tier memory in a tiered memory](https://lore.kernel.org/patchwork/patch/1408180) | memory tiers 的配置管理. 监控系统和每个 cgroup 中各自使用的 top-tier 内存的数量. 当前使用了 soft limit, 用 kswapd 来把某个 cgroup 中超过 soft limit 限制的 page 迁移到较慢的 memory 类型上去. 这里所说的 soft limit, 是指如果 top-tier memory 很充足的话, cgroup 可以拥有超过此限制的 page 数量, 但如果资源紧张的话则会被迅速削减从而满足这个 limit 值. 后期可用于对于不同的任务划分快、慢内存(fast and slow memory). 即让高优先级的任务获得更多 top-tier memory 访问优先, 而低优先级的任务则要受到更严格的限制 | v1 ☐ 5.13 | [PatchWork RFC,v1,00/11](https://patchwork.kernel.org/project/linux-mm/cover/cover.1617642417.git.tim.c.chen@linux.intel.com/) | | 2021/07/15 | Dave Hansen
Huang Ying | [Migrate Pages in lieu of discard](https://lore.kernel.org/patchwork/patch/1393431) | 页面回收阶段引入页面降级(demote pages)策略. 在一个具备了持久性内存的系统中(这些系统具有多种类型的内存, 具有不同的性能特征, 而不是普通 NUMA 系统, 在普通 NUMA 系统中, 相同类型的内存存在于不同的距离), 在回收期间允许页面迁移使这些系统能够在快速层承受压力时将页面从快速层迁移到慢速层. 具体做法是可以把一些需要回收的 page 从 DRAM 迁移到较慢的 memory 中, 后面如果再次需要这些数据了, 也是仍然可以直接访问到, 只是速度稍微慢一些. 目前的版本还不完善, 被迁移的 page 将被永远困在慢速内存区域中, 没有机制使其回到更快的 DRAM.(Huang Ying 后续工作, 重新调整 autonuma 的用途, 将热门页面推广回 DRAM). 这个降级策略可以通过 sysctl 的 ~~vm.zone_reclaim_mode 中把 bitmask 设置为 8 从而启用这个功能~~ `/sys/kernel/mm/numa/demotion_enabled` 开关来控制. 参见报道 [Linux 5.15 Has A Critical Improvement For Tiered Memory Servers](https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.15-Demote-During-Reclai). | v10 ☑ 5.15-rc1 | [PatchWork -V10,0/9](https://patchwork.kernel.org/project/linux-mm/cover/20210715055145.195411-1-ying.huang@intel.com), [PatchWork -V10,0/9](https://lore.kernel.org/all/20210715055145.195411-1-ying.huang@intel.com), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=26aa2d199d6f2cfa6f2ef2a5dfe891f2250e71a0) | -| 2021/11/16 | Huang Ying | [NUMA balancing: optimize memory placement for memory tiering system](https://www.phoronix.com/scan.php?page=news_item&px=Intel-Optimize-PMEM-Place-v9) | 将经常使用的 page 从慢速内存迁移到快速内存的方案. 对 Linux 内核的 NUMA balancing 行为进行了调整, 以优化内存分层系统的内存位置. 这些补丁进一步优化了内核在持久内存存在的情况下对页面的处理, 同时将最重要的页面保留在 DRAM 中.
优化 numa balancing 的页面迁移策略, 利用了这些 numa fault 来对哪些 page 属于常用 page 进行更准确地估算. 新的策略依据从 page unmmap 到发生 page fault 之间的时间差来判断 page 是否常用, 并提供了一个 sysctl 开关来定义阈值: kernel.numa_balancing_hot_threshold_ms. 所有 page fault 时间差低于阈值的 page 都被判定是常用 page. 由于对于系统管理员来说可能很难决定这个阈值应该设置成什么值, 所以这组 patch 中的实现了自动调整的方法. 为了实现这个自动调整, kernel 会根据用户设置的平衡速率限制(balancing rate limit). 内核会对迁移的 page 数量进行监控, 通过增加或减少阈值来使 balancing rate 更接近该目标值. 仓库地址 [vishal/tiering.git](https://git.kernel.org/pub/scm/linux/kernel/git/vishal/tiering.git/log/?h=tiering-0.72). 参见报道 [Intel Continues Optimizing Linux For Optane DC Persistent Memory Servers](https://www.phoronix.com/scan.php?page=news_item&px=Intel-Optimize-PMEM-Place-v9) | v10 ☐ 5.15 | [PatchWork RFC,-V6,0/6](https://lore.kernel.org/patchwork/patch/1393431)
*-*-*-*-*-*-*-*
[PatchWork -V8,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20210914013701.344956-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[PatchWork -V9,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211008083938.1702663-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[PatchWork -V10,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211116013522.140575-1-ying.huang@intel.com) | -| 2022/02/21 | Huang Ying | [NUMA balancing: optimize memory placement for memory tiering system](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=a1a3a2fc304df326ff67a1814364f640f2d5121c) | 616201 | v1 ☑ 5.18-rc1 | [LORE v13,0/3](https://lore.kernel.org/r/20220221084529.1052339-1-ying.huang@intel.com) | +| 2022/02/21 | Huang Ying | [NUMA balancing: optimize memory placement for memory tiering system](https://www.phoronix.com/scan.php?page=news_item&px=Intel-Optimize-PMEM-Place-v9) | 将经常使用的 page 从慢速内存迁移到快速内存的方案. 对 Linux 内核的 NUMA balancing 行为进行了调整, 以优化内存分层系统的内存位置. 这些补丁进一步优化了内核在持久内存存在的情况下对页面的处理, 同时将最重要的页面保留在 DRAM 中.
优化 numa balancing 的页面迁移策略, 利用了这些 numa fault 来对哪些 page 属于常用 page 进行更准确地估算. 新的策略依据从 page unmmap 到发生 page fault 之间的时间差来判断 page 是否常用, 并提供了一个 sysctl 开关来定义阈值: kernel.numa_balancing_hot_threshold_ms. 所有 page fault 时间差低于阈值的 page 都被判定是常用 page. 由于对于系统管理员来说可能很难决定这个阈值应该设置成什么值, 所以这组 patch 中的实现了自动调整的方法. 为了实现这个自动调整, kernel 会根据用户设置的平衡速率限制(balancing rate limit). 内核会对迁移的 page 数量进行监控, 通过增加或减少阈值来使 balancing rate 更接近该目标值. 仓库地址 [vishal/tiering.git](https://git.kernel.org/pub/scm/linux/kernel/git/vishal/tiering.git/log/?h=tiering-0.72). 参见报道 [Intel Continues Optimizing Linux For Optane DC Persistent Memory Servers](https://www.phoronix.com/scan.php?page=news_item&px=Intel-Optimize-PMEM-Place-v9) | v13 ☑ 5.18-rc1 | [PatchWork RFC,-V6,0/6](https://lore.kernel.org/patchwork/patch/1393431)
*-*-*-*-*-*-*-*
[PatchWork -V8,0/6](https://patchwork.kernel.org/proje3t/linux-mm/cover/20210914013701.344956-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[PatchWork -V9,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211008083938.1702663-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[PatchWork -V10,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211116013522.140575-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[LORE v13,0/3](https://lore.kernel.org/r/20220221084529.1052339-1-ying.huang@intel.com) | | 2021/11/24 | Hasan Al Maruf | [Transparent Page Placement for Tiered-Memory](https://patchwork.kernel.org/project/linux-mm/cover/cover.1637778851.git.hasanalmaruf@fb.com) | 由于不同类型的内存对性能的影响程度不同, 因此如何跨 NUMA 节点管理页面应该是一个值得关注的问题. Dave Hansen 的补丁集 ["Migrate Pages in replace of discard"](https://lwn.net/Articles/860215) 在回收过程中将顶级页面降级到慢级节点. 然而, 他的补丁集不包括将慢层内存节点上的页面提升到顶级内存节点的功能. 因此, 在慢层节点上降级或新分配的页面将经历 NUMA 延迟, 并损害应用程序性能. 在这个补丁集中,
1. 通过增强现有的 AutoNUMA 机制, 将页面从慢级节点提升到顶级节点.
2. 将顶级节点的回收和分配逻辑解耦, 以便回收在更高的水印处触发, 并将较冷的页面降级到慢层内存中. 因此, 顶级节点可以保留一些空闲空间, 以接受来自慢级节点的新分配和提升.
在对页面升级期间, 添加滞后性, 只升级那些在短时间内不太可能被降级页面. 这减少了页面在短时间内频繁降级和提升而在 NUMA 节点之间来回跳转的机会. 作者在支持 cxl 的 DRAM 和 PMEM 层的系统上测试了这个补丁集. 可以将较热的页面转移到顶级节点, 而将较冷的页面移动到慢层节点, 从而产生大量的 Meta 生产工作负载和实时流量. 因此, 顶级节点提供更多的热页面, 应用程序的性能也得到了提高. 将 80% 的匿名者带到顶级节点. 慢层内存中的匿名页大多是冷页. 由于顶级节点不能承载所有热内存, 一些热文件仍然留在慢级节点上. 尽管如此, 远程 NUMA 读带宽从 80% 减少到 40%. 与服务于整个工作集的顶级节点的基线相比, 使用这个补丁集的吞吐量回归仅为 5%. 参见报道 [Facebook/Meta Tackling Transparent Page Placement For Tiered-Memory Linux Systems](https://www.phoronix.com/scan.php?page=news_item&px=Meta-Hot-Pages-High-Tiers). | v1 ☐ | [PatchWork 0/5]https://patchwork.kernel.org/project/linux-mm/cover/cover.1637778851.git.hasanalmaruf@fb.com) | | 2021/12/11 | Baolin Wang | [Add speculative numa fault support](https://lore.kernel.org/patchwork/patch/1479229) | 这个 RFC 补丁集为分级内存等场景添加了推测性的 numa 错误支持. 在分层内存系统上, 它将依靠 numa 平衡将慢内存和热内存提升为快内存, 以提高性能. 因此, 我们可以根据某些工作负载的数据局部性, 提前在低速内存中提升多个顺序页面, 以提高性能. 那么现在有多少页面需要提升到最快的内存是最好的? 现在这个 RFC 补丁集只实现了一个基本而简单的机制来推测每个 VMA 的 numa 故障窗口. 它将为每个 VMA 引入一个新的原子成员来记录 numa 故障窗口信息, 该信息用于确定它是扩展还是减少 numa 故障窗口的顺序流. 在分层内存系统中测试 mysql 可以看到大约 6% 的改进. 注意: 这个补丁集是[基于实现分级内存提升的补丁集 NUMA balancing: optimize page placement for memory tiering system](https://lore.kernel.org/lkml/87bl2gsnrd.fsf@yhuang6-desk2.ccr.corp.intel.com). 参见报道 [Speculative NUMA Fault Support Proposed For Improving Tiered Memory Linux Performance](https://www.phoronix.com/scan.php?page=news_item&px=Speculative-NUMA-Fault) | v1 ☐ | [LORE](https://lore.kernel.org/lkml/cover.1639306956.git.baolin.wang@linux.alibaba.com), [PatchWork](https://patchwork.kernel.org/project/linux-mm/cover/cover.1639306956.git.baolin.wang@linux.alibaba.com) | +| 2022/04/08 | Huang Ying | [memory tiering: hot page selection](https://patchwork.kernel.org/project/linux-mm/cover/20220408071222.219689-1-ying.huang@intel.com/) | 在分级内存的系统中, 需要使用 NUMA 来优化页面在内存中的位置. 基本上, 最初的 NUMA Balancing 实现选择并提升最近访问最多(mostly recently accessed/MRU)的页面. 但最近访问的页面可能很冷. 因此, 在这个补丁集中, 我们基于 NUMA 平衡页表扫描和页面 Page Fault & Hint 之间的延迟实现了一个新的热页识别算法. 另外一方面热页升级可能会在系统中产生一些开销. 为了控制开销, 实现了一种简单的提升速率限制机制. 用于识别热页的热阈值通常取决于工作负载. 因此, 我们还实现了一个热页阈值自动调整算法. 基本思想是增加/减少热页阈值, 使通过热页阈值提升到快速内存的页面数接近速率限制. | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20220408071222.219689-1-ying.huang@intel.com) | ## 12.5 异构内存(CPU & GPU) diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index a6945a8..0605279 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -2382,17 +2382,48 @@ Xen 的 CPU 调度算法主要有 3 种: BVT(borrowed virtual time)调度算法 "Google Fibers" 是一个用户空间调度框架, 在谷歌广泛使用并成功地用于改善进程内工作负载隔离和响应延迟. 我们正在开发这个框架, UMCG(用户管理并发组)内核补丁是这个框架的基础. +#### 11.2.1.1 Directly Switch To +------- [FUTEX_SWAP补丁分析-SwitchTo 如何大幅度提升切换性能？](https://mp.weixin.qq.com/s/dDg5WKb8vqo5WfArAuav9Q) | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2020/08/03 | Peter Oskolkov / | [FUTEX_SWAP](https://lore.kernel.org/patchwork/cover/1433967) | 通过对 futex 的魔改, 使得在用户态使用 switch_to() 指定任务切换的能力. 这就是用户模式线程的用途: 极低的切换开销, 意味着我们操作系统可以支持的数以千计的线程可以提高到 10 倍以上甚至百万级别. | [2020/06/15 PatchWork RFC,0/3](https://lore.kernel.org/patchwork/cover/1256264)
*-*-*-*-*-*-*-*
[2020/06/16 PatchWork RFC,0/3,v2](https://lore.kernel.org/patchwork/cover/1257233)
*-*-*-*-*-*-*-*
[2021/07/16 PatchWork RFC,0/3,v3](https://lore.kernel.org/patchwork/cover/1263506)
*-*-*-*-*-*-*-*
[2020/08/03 PatchWork for,5.9,v2,0/4](https://lore.kernel.org/patchwork/cover/1283798) | -| 2021/12/14 | Peter Oskolkov / | [sched,mm,x86/uaccess: implement User Managed Concurrency Groups](https://lore.kernel.org/patchwork/cover/1433967) | UMCG (User-Managed Concurrency Groups) | [PatchWork RFC,v0.1,0/9](https://lore.kernel.org/patchwork/cover/1433967)
*-*-*-*-*-*-*-*
[2021/07/08 PatchWork RFC,0/3,v0.2](https://lore.kernel.org/patchwork/cover/1455166)
*-*-*-*-*-*-*-*
[2021/07/16 PatchWork RFC,0/4,v0.3](https://lore.kernel.org/patchwork/cover/1461708)
*-*-*-*-*-*-*-*
[2021/08/01 PatchWork 0/4,v0.4](https://lore.kernel.org/patchwork/cover/1470650)
*-*-*-*-*-*-*-*
[2021/08/01 LWN 0/4,v0.5](https://lore.kernel.org/patchwork/cover/1470650)
*-*-*-*-*-*-*-*
[2021/10/12 PatchWork v0.7,0/5](https://patchwork.kernel.org/project/linux-mm/cover/20211012232522.714898-1-posk@google.com)
*-*-*-*-*-*-*-*
[2021/11/04 PatchWork v0.8,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211104195804.83240-1-posk@google.com)
*-*-*-*-*-*-*-*
[2021/11/21 PatchWork v0.9,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211121212040.8649-1-posk@google.com)
*-*-*-*-*-*-*-*
[2021/11/23 PatchWork v0.9.1,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211122211327.5931-1-posk@google.com) | -| 2016/02/19 | Paul Gortmaker | [sched: User Managed Concurrency Groups](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=abedf8e2419fb873d919dd74de2e84b510259339) | 引入 hugetlb cgroup | v9 ☑ 4.6-rc1 | [PatchWork RFC,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211214204445.665580974@infradead.org)
*-*-*-*-*-*-*-*
[PatchWork RFC,v2,0/5](https://patchwork.kernel.org/project/linux-mm/cover/20220120155517.066795336@infradead.org) | + +### 11.2.1.2 ghOSt +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/09/08 | Peter Oskolkov / | [google ghOSt](https://github.com/google/ghost-kernel) | ghOSt 是在 Linux 内核上实现的用户态调度策略的通用代理. ghOSt 框架提供了一个丰富的 API, 该 API 从用户空间接收进程的调度决策, 并将其作为事务执行. 程序员可以使用任何语言或工具来开发策略, 这些策略可以在不重新启动机器的情况下升级. ghOSt 支持一系列调度目标的策略, 从 µs 级延迟到吞吐量, 再到能源效率, 等等, 并且调度操作的开销较低. 许多策略只是几百行代码. 总之, ghOSt 提供了一个性能框架, 用于将线程调度策略委托给用户空间进程, 从而实现策略优化、无中断升级和故障隔离. | [github kernel](https://github.com/google/ghost-kernel)
*-*-*-*-*-*-*-*
[github userspace](https://github.com/google/ghost-userspace) | +### 11.2.1.3 UMCG +------- + +2021 年, Google 宣布开源他们的 Fibers 用户空间调度框架的计划, 并向 Linux Kernel 社区发送了 UMCG 的内核补丁集合. [LWN: UMCG(User-managed concurrency groups)](https://lwn.net/Articles/879398) 用户并发进程组是一组用户态调度框架, 它提供了一个 M:N 线程子系统和工具集合 ToolKit, 允许开发人员实现进程内用户空间调度程序. 其思想来源于 1992 年的论文 [Scheduler activations: effective kernel support for the user-level management of parallelism](https://dl.acm.org/doi/abs/10.1145/146941.146944). 参见 [Google Continues Work On User-Managed Concurrency Groups For Linux](https://www.phoronix.com/scan.php?page=news_item&px=Google-UMCG-Linux-v0.7). + +UMCG 要求多线程应用程序将自己划分为"服务线程 Server"和"工作线程 Worker", 其中系统上的每个 CPU 可能有一个服务线程 Server. 服务线程 Server 做出调度决策, 而工作人员根据这些决策运行并完成实际工作. UMCG 的优势在于, 调度可以快速发生, 并且内核的开销很小. + +据 Google 公开资料透露, UMCG 在 Google 用于 2 个场景: 安全沙箱和用户空间调度(比如协程框架等). 参见 [Google Makes New Attempt At "UMCG" As Part Of Their Open-Sourcing Effort Around Fibers](https://www.phoronix.com/scan.php?page=news_item&px=Google-UMCG-0.2-Fibers) 以及 [Google Working On Open-Sourcing Their Fibers User-Space Scheduling Framework](https://www.phoronix.com/scan.php?page=news_item&px=Google-Fibers-Toward-Open). + +| 使用场景 | 描述 | 解决问题 | +|:-------:|:---:|:-------:| +| 安全沙箱 | 快速的 X-process 上下文切换将为更多用例打开一堆轻量级的安全工具, 例如 gVisor 或 Tor Project 的 Shadow 模拟器. | NA | +| 用户态调度 | Google 广泛使用进程内用户空间调度, 为各种工作负载提供延迟控制和隔离保证, 同时保持高 CPU 利用率. | 1. 使用协程等, 可以很好的处理用户态 wait 等语义, 但是如果协程实际的载体进程/线程因为系统调用或者 IO 等阻塞, 协程库无法及时感知, 从而造成其他协程也不能执行. 通过 UMCG 提供的 upcall 机制, 可以在协程的执行线程 Worker 阻塞后, 通过 UMCG Server 拉起新的执行线程 Worker 来执行.
2. 此外可以把 Worker 的调度策略也放到用户态, 每次协程甚至是 Worker 的 PICK NEXT, 都可以交给用户态调度策略来完成. | + +Google 的 Peter Oskolkov 发布了[最早的 RFC v0.1 补丁](https://lore.kernel.org/lkml/20210520183614.1227046-1-posk@google.com), 并持续工作到 [v0.9.1](https://lore.kernel.org/lkml/20211122211327.5931-1-posk@google.com). 但是社区对此特性一直没有达成一致意见. + +随后, Peter Zijlstra 对 UMCG 进行了重新设计 [UMCG RFC,0/3](https://lwn.net/ml/linux-kernel/20211214204445.665580974@infradead.org), 参见 [社区讨论](https://lore.kernel.org/lkml/20211215222524.GH16608@worktop.programming.kicks-ass.net). + + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2021/12/14 | Peter Oskolkov / | [sched,mm,x86/uaccess: implement User Managed Concurrency Groups](https://lore.kernel.org/patchwork/cover/1433967) | UMCG (User-Managed Concurrency Groups) | [PatchWork RFC,v0.1,0/9](https://lore.kernel.org/patchwork/cover/1433967)
*-*-*-*-*-*-*-*
[2021/07/08 PatchWork RFC,0/3,v0.2](https://lore.kernel.org/patchwork/cover/1455166)
*-*-*-*-*-*-*-*
[2021/07/16 PatchWork RFC,0/4,v0.3](https://lore.kernel.org/patchwork/cover/1461708)
*-*-*-*-*-*-*-*
[2021/08/01 PatchWork 0/4,v0.4](https://lore.kernel.org/patchwork/cover/1470650)
*-*-*-*-*-*-*-*
[2021/08/01 LWN 0/4,v0.5](https://lore.kernel.org/patchwork/cover/1470650)
*-*-*-*-*-*-*-*
[2021/10/12 PatchWork v0.7,0/5](https://patchwork.kernel.org/project/linux-mm/cover/20211012232522.714898-1-posk@google.com)
*-*-*-*-*-*-*-*
[2021/11/04 PatchWork v0.8,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211104195804.83240-1-posk@google.com)
*-*-*-*-*-*-*-*
[2021/11/21 PatchWork v0.9,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211121212040.8649-1-posk@google.com)
*-*-*-*-*-*-*-*
[2021/11/23 PatchWork v0.9.1,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211122211327.5931-1-posk@google.com) | +| 2022/01/20 | Paul Gortmaker | [sched: User Managed Concurrency Groups](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=abedf8e2419fb873d919dd74de2e84b510259339) | Peter Zijlstra 对 UMCG 的重新实现. | v9 ☑ 4.6-rc1 | [PatchWork RFC,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211214204445.665580974@infradead.org)
*-*-*-*-*-*-*-*
[PatchWork RFC,v2,0/5](https://patchwork.kernel.org/project/linux-mm/cover/20220120155517.066795336@infradead.org) | + + ### 11.2.2 Scheduler BPF ------- @@ -2419,6 +2450,9 @@ BPF 钩子(它已经成功地用于各种内核子系统)为外部代码(安全 * Facebook 的尝试 +[当 BPF 邂逅 CPU 调度器](https://www.ebpf.top/post/cfs_scheduler_bpf) + + Roman Gushchin 在邮件列表发起了 BPF 对调度器的潜在应用的讨论, 它提交的 patchset 旨在为调度器提供一些非常基本的 BPF 基础设施, 以便向调度器添加新的 BPF钩子、一组最小的有用助手以及相应的 libbpf 更改等等. 他们在 CFS 中使用 BPF 的第一次实验看起来非常有希望. 虽然还处于非常早期的阶段, 但在 Facebook 的主网页工作量已经获得了不错的延迟和约 1% 的 RPS. 参见 [LWN: Controlling the CPU scheduler with BPF](https://lwn.net/Articles/873244), 以及 [Early Patches Bring BPF To The Linux Scheduler](https://www.phoronix.com/scan.php?page=news_item&px=Linux-BPF-Scheduler). 作者提供了一个用户空间部分的示例 [github/rgushchin/atc](https://github.com/rgushchin/atc), 它加载了一些简单的钩子. 它非常简单, 只是为了简化使用所提供的内核补丁.