From c3190982e6ba32e9365cb229e1cf9253c487e6f7 Mon Sep 17 00:00:00 2001 From: gatieme Date: Sat, 6 Nov 2021 11:46:32 +0800 Subject: [PATCH] description/memory: update to day 20211105 --- study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md | 18 ++++++++++-------- study/kernel/00-DESCRIPTION/SCHEDULER.md | 2 +- 2 files changed, 11 insertions(+), 9 deletions(-) diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index d2879fd..58308de 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -95,12 +95,13 @@ ## 0.3 主线内存管理分支合并窗口 ------- -Mainline Merge Window - Merge branch 'akpm' (patches from Andrew) +Andrew Morton 一般以一封 [incoming](https://lore.kernel.org/linux-mm/20211105133408.cccbb98b71a77d5e8430aba1@linux-foundation.org) 的邮件向 Linus 发起 push 请求, Linus pull 之后的 Merge 标题为 Merge branch 'akpm' (patches from Andrew). | 版本 | 发布时间 | 合并链接 | |:---:|:-------:|:-------:| | 5.13 | 2021/06/28 | [5.13-rc1 step 1 2021/04/30](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d42f323a7df0b298c07313db00b44b78555ca8e6)
[5.13-rc1 step 2 2021/05/05](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8404c9fbc84b741f66cff7d4934a25dd2c344452)
[5.13-rc2 2021/05/15](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4147415bdf152748416e391dd5d6958ad0a96da)
[5.13-rc3 2021/05/22](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34c5c89890d6295621b6f09b18e7ead9046634bc)
[5.13-rc5 2021/06/05](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e5220dd16778fe21d234a64e36cf50b54110025f)
[5.13-rc7 2021/06/16](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=70585216fe7730d9fb5453d3e2804e149d0fe201)
[5.13 2021/06/25](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7ce32ac6fb2fc73584b567c73ae0c47528954ec6) | | 5.14 | NA | [5.14 2021/06/29](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65090f30ab791810a3dc840317e57df05018559c) | +| 5.14 | NA | [5.14 2021/06/29](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65090f30ab791810a3dc840317e57df05018559c) | ## 0.4 社区会议 @@ -322,6 +323,7 @@ Linux 一开始是在一台i386上的机器开发的, i386 的硬件页表是2 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/08/23 | Mike Rapoport | [mm/page_alloc: cache pte-mapped allocations](https://lore.kernel.org/patchwork/cover/1480366) | NA | v1 ☐ | [PatchWork RFC,0/4](https://lore.kernel.org/patchwork/cover/1480366) | +| 2021/10/26 | Pasha Tatashin | [Hardening page _refcount](https://patchwork.kernel.org/project/linux-mm/cover/20211026173822.502506-1-pasha.tatashin@soleen.com) | 目前很难找出原因 `_refcount` 问题的根源, 因为它们通常在损坏发生后才会出现. 然而, 它们可能导致灾难性的故障, 如内存损坏.
通过添加更多的检查来提高可调试性, 确保 `page->_refcount` 永远不会变成负数(例如, 双空闲不发生, 或冻结后空闲等).
1. 增加了对 `_refcount` 异常值的检测.
2. 删除了 set_page_count(), 这样就不会无条件地用不受限制的值覆盖 `_refcount` | RFC,0/8 ☐ | [PatchWork RFC,0/8](https://patchwork.kernel.org/project/linux-mm/cover/20211026173822.502506-1-pasha.tatashin@soleen.com) | ### 1.7.3 安全 @@ -625,7 +627,7 @@ Mel Gorman 发现了这一问题, 开发了 [Calculate pcp->high based on zone s | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/09/21 | Sebastian Andrzej Siewior | [mm/swap: Add static key dependent pagevec locking](https://patchwork.kernel.org/project/linux-mm/cover/20190424111208.24459-1-bigeasy@linutronix.de) | 本系列实现了swap 的代码路径中通过禁用抢占来同步它对 per-cpu pagevec 结构体的访问. 这是可行的, 需要从中断上下文访问的结构体是通过禁用中断来保护的.
有一种情况下, 需要访问远程 CPU 的 per-cpu 数据, 在 v1 版本中, 试图添加每个 cpu 的自旋锁来访问结构体. 这将增加 lockdep 覆盖率和从远程 CPU 的访问, 不需要 worker.
在 v2 中这是通过在远程 CPU 上启动一个 worker 并等待它完成来解决的.
关于无争用 spin_lock () 的代价, 以及避免每个 cpu worker 的好处很少, 因为它很少被使用. 然后听从社区的建议使用 static key use_pvec_lock, 在某些情况下(如 NOHZ_FULL 情况), 它支持每个 cpu 的锁定. | v1 ☐ | [PatchWork 0/4,v2](https://patchwork.kernel.org/project/linux-mm/cover/20190424111208.24459-1-bigeasy@linutronix.de) | -| 2021/09/21 | Nicolas Saenz Julienne | [mm: Remote LRU per-cpu pagevec cache/per-cpu page list drain support](https://patchwork.kernel.org/project/linux-mm/cover/20210921161323.607817-1-nsaenzju@redhat.com) | 本系列介绍了 mm/swap.c 的每个 CPU LRU pagevec 缓存和 mm/page_alloc 的每个 CPU 页面列表的另一种锁定方案 remote_pcpu_cache_access, 这将允许远程 CPU 消耗它们.
目前, 只有一个本地 CPU 被允许更改其每个 CPU 列表, 并且当进程需要它时, 它会按需这样做 (通过在本地 CPU 上排队引流任务).
大多数系统会迅速处理这个问题, 但它会给 NOHZ_FULL CPU 带来问题, 这些 CPU 无法在不破坏其功能保证(延迟、带宽等) 的情况下接受任何类型的中断. 如果这些进程能够远程耗尽列表本身, 就可以与隔离的 CPU 共存, 但代价是更多的锁约束.
通过 static key remote_pcpu_cache_access 来控制该特性的开启与否, 对于非 nohz_full 用户来说, 默认禁用它, 这保证了最小的功能或性能退化. 而只有当 NOHZ_FULL 的初始化过程成功时, 该特性才会被启用. | v1 ☐ | [PatchWork 0/6](https://patchwork.kernel.org/project/linux-mm/cover/20210921161323.607817-1-nsaenzju@redhat.com) | +| 2021/09/21 | Nicolas Saenz Julienne | [mm: Remote LRU per-cpu pagevec cache/per-cpu page list drain support](https://patchwork.kernel.org/project/linux-mm/cover/20210921161323.607817-1-nsaenzju@redhat.com) | 本系列介绍了 mm/swap.c 的每个 CPU LRU pagevec 缓存和 mm/page_alloc 的每个 CPU 页面列表的另一种锁定方案 remote_pcpu_cache_access, 这将允许远程 CPU 消耗它们.
目前, 只有一个本地 CPU 被允许更改其每个 CPU 列表, 并且当进程需要它时, 它会按需这样做 (通过在本地 CPU 上排队引流任务).
大多数系统会迅速处理这个问题, 但它会给 NOHZ_FULL CPU 带来问题, 这些 CPU 无法在不破坏其功能保证(延迟、带宽等) 的情况下接受任何类型的中断. 如果这些进程能够远程耗尽列表本身, 就可以与隔离的 CPU 共存, 但代价是更多的锁约束.
通过 static key remote_pcpu_cache_access 来控制该特性的开启与否, 对于非 nohz_full 用户来说, 默认禁用它, 这保证了最小的功能或性能退化. 而只有当 NOHZ_FULL 的初始化过程成功时, 该特性才会被启用. | v2 ☐ | [2021/09/21 PatchWork 0/6](https://patchwork.kernel.org/project/linux-mm/cover/20210921161323.607817-1-nsaenzju@redhat.com)
*-*-*-*-*-*-*-*
[2021/11/03 PatchWork v2,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211103170512.2745765-1-nsaenzju@redhat.com) | ### 2.2.6 ALLOC_NOFRAGMENT 优化 @@ -950,8 +952,6 @@ https://lore.kernel.org/patchwork/cover/668967 | 2019/10/22 | Uladzislau Rezki (Sony) | [mm/vmalloc: rework vmap_area_lock](https://lore.kernel.org/patchwork/cover/1143029) | 随着 5.2 版本 [improve vmap allocation](https://lore.kernel.org/patchwork/cover/1059021) 的合入, 全局的 vmap_area_lock 可以被拆分成两个锁: 一个用于分配部分(vmap_area_lock), 另一个用于回收(free_vmap_area_lock), 因为有两个不同的实体: "空闲数据结构"和"繁忙数据结构". 这和那后的减少锁争用, 允许在不同的 CPU 上并行执行"空闲"和"忙碌"树的操作. 但是需要注意的是, 分配/释放操作仍然存在依赖. 如果在不同的 CPU 上同时运行, 分配/释放操作仍然会相互干扰. | v1 ☑ 5.5-rc1 | [PatchWork v2,0/8](https://patchwork.kernel.org/project/linux-mm/patch/20191022155800.20468-1-urezki@gmail.com)
*-*-*-*-*-*-*-*
[commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e36176be1c3920a487681e37158849b9f50189c4) | - - #### 2.4.1.3 lazy drain ------- @@ -992,7 +992,7 @@ vmap_block 是内核每次预先分配的 per-cpu vmap 缓存块, vmap_block_que | 2008/07/28 | Nick Piggin | [mm, vmalloc: cleanup for vmap block](https://lore.kernel.org/patchwork/patch/384995) | 删除了 vmap block 中的一些死代码和不用代码. 其中 vb_alloc() 中 vmap_block 中如果有足够空间是必然分配成功的, 因此删除了 bitmap_find_free_region() 相关的 purge 代码. | RFC ☑ 2.6.28-rc1 | [PatchWork 0/3](https://lore.kernel.org/patchwork/cover/384995)
*-*-*-*-*-*-*-*
[commit](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3fcd76e8028e0be37b02a2002b4f56755daeda06) | -https://lore.kernel.org/patchwork/cover/616606/ +https://lore.kernel.org/patchwork/patch/616606/ https://lore.kernel.org/patchwork/patch/164572/ commit f48d97f340cbb0c323fa7a7b36bd76a108a9f49f @@ -1062,7 +1062,7 @@ vmalloc_to_page 则提供了通过 vmalloc 地址查找到对应 page 的操作. | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2021/10/18 | Alistair Popple | [extend vmalloc support for constrained allocations](https://patchwork.kernel.org/project/linux-mm/cover/20211018114712.9802-1-mhocko@kernel.org) | 第一个补丁为 vmalloc 实现 NOFS/NOIO支持. 第二个补丁增加了 NOFAIL 支持, 第三个补丁将所有支持打包到 kvmalloc 中, 并删除了现在可以直接使用 kvmalloc 的 ceph_kvmalloc. | v2 ☑ 4.13-rc1 | [PatchWork RFC,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211018114712.9802-1-mhocko@kernel.org) | +| 2021/10/25 | Alistair Popple | [extend vmalloc support for constrained allocations](https://patchwork.kernel.org/project/linux-mm/cover/20211018114712.9802-1-mhocko@kernel.org) | 第一个补丁为 vmalloc 实现 NOFS/NOIO支持. 第二个补丁增加了 NOFAIL 支持, 第三个补丁将所有支持打包到 kvmalloc 中, 并删除了现在可以直接使用 kvmalloc 的 ceph_kvmalloc. | v2 ☑ 4.13-rc1 | [2021/10/18 PatchWork RFC,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211018114712.9802-1-mhocko@kernel.org)
*-*-*-*-*-*-*-*
[2021/10/25 PatchWork 0/4](https://patchwork.kernel.org/project/linux-mm/cover/20211025150223.13621-1-mhocko@kernel.org) | @@ -2142,7 +2142,7 @@ Linux 内核在脏页数量到达一定门槛时, 或者用户在命令行输入 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2020/12/22 | Liang Li | [add support for free hugepage reporting](https://lore.kernel.org/patchwork/cover/1355899) | Free page reporting 只支持伙伴系统中的页面, 它不能报告为 hugetlbfs 预留的页面. 这个补丁在 hugetlb 的空闲列表中增加了对报告巨大页的支持, 它可以被 virtio_balloon 驱动程序用于内存过载和预归零空闲页, 以加速内存填充和页面错误处理. | RFC ☐ | [PatchWork RFC,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20201222074538.GA30029@open-light-1.localdomain) | -| 2021/10/07 | Mike Kravetz | [hugetlb: add demote/split page functionality](https://lore.kernel.org/patchwork/cover/1465517) | 实现了 hugetlb 降低策略. 提供了一种“就地”将 hugetlb 页面分割为较小的页面的方法. | v1 ☐ | [2021/07/21 PatchWork 0/8](https://patchwork.kernel.org/project/linux-mm/cover/20210721230511.201823-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[2021/08/16 PatchWork RESEND,0/8](https://patchwork.kernel.org/project/linux-mm/cover/20210816224953.157796-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[2021/09/23 PatchWork v2,0/4](https://patchwork.kernel.org/project/linux-mm/cover/20210923175347.10727-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[2021/10/07 PatchWork v4,0/5](https://patchwork.kernel.org/project/linux-mm/cover/20211007181918.136982-1-mike.kravetz@oracle.com) | +| 2021/10/07 | Mike Kravetz | [hugetlb: add demote/split page functionality](https://lore.kernel.org/patchwork/cover/1465517) | 实现了 hugetlb 降低策略. 提供了一种“就地”将 hugetlb 页面分割为较小的页面的方法. | v4 ☐ | [2021/07/21 PatchWork 0/8](https://patchwork.kernel.org/project/linux-mm/cover/20210721230511.201823-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[2021/08/16 PatchWork RESEND,0/8](https://patchwork.kernel.org/project/linux-mm/cover/20210816224953.157796-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[2021/09/23 PatchWork v2,0/4](https://patchwork.kernel.org/project/linux-mm/cover/20210923175347.10727-1-mike.kravetz@oracle.com)
*-*-*-*-*-*-*-*
[2021/10/07 PatchWork v4,0/5](https://patchwork.kernel.org/project/linux-mm/cover/20211007181918.136982-1-mike.kravetz@oracle.com) | | 2021/10/14 | Mina Almasry | [mm, hugepages: add mremap() support for hugepage backed vma](https://patchwork.kernel.org/project/linux-mm/patch/20210730221522.524256-1-almasrymina@google.com) | 通过简单地重新定位页表项, 使得 mremap() 支持 hugepage 的 vma 段. 页表条目被重新定位到 mremap() 上的新虚拟地址.
作者验证的测试场景是一个简单的 bench: 它在 hugepages 中重新加载可执行文件的 ELF 文本, 这大大提高了上述可执行文件的执行性能.
将 hugepages 上的 mremap 操作限制为原始映射的大小, 因为底层 hugetlb 保留还不能处理到更大的大小的重映射.
在 mremap () 操作期间, 我们检测 pmd_shared 的映射, 并在 mremap () 期间取消这些映射的共享. 在访问和故障时, 再次建立共享. | v1 ☐ | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/20210730221522.524256-1-almasrymina@google.com)
*-*-*-*-*-*-*-*
[PatchWork v4,1/2](https://patchwork.kernel.org/project/linux-mm/patch/20211006194515.423539-1-almasrymina@google.com)
*-*-*-*-*-*-*-*
[PatchWork v8,1/2](https://patchwork.kernel.org/project/linux-mm/patch/20211014200542.4126947-1-almasrymina@google.com) | | 2021/09/30 | Baolin Wang | [Support hugetlb charge moving at task migration](https://patchwork.kernel.org/project/linux-mm/cover/cover.1632843268.git.baolin.wang@linux.alibaba.com) | 现在在 hugetlb cgroup 中, 任务迁移时与任务相关的统计不会移动到新的 hugetlb cgroup 中, 这对于 hugetlb cgroup 的使用是奇怪的. 这个补丁集增加了 hugetlb cgroup 中迁移任务时统计信息的迁移. | v1 ☐ | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/cover/cover.1632843268.git.baolin.wang@linux.alibaba.com) | | 2021/10/05 | Zhenguo Yao | [hugetlbfs: Extend the definition of hugepages parameter to support node allocation](https://lore.kernel.org/patchwork/cover/1479318) | 当前内核允许指定启动时要分配的 hugepages 数目. 但目前所有节点的 hugepages 都是平衡的. 在某些场景中, 我们只需要在一个节点中使用 hugepags.
例如: DPDK 需要与 NIC 位于同一节点的 hugepages. 如果 DPDK 在 node1 中需要 4 个 1G 大小的 HugePage, 并且系统有 16 个 numa 节点. 我们必须在内核 cmdline 中保留 64 个 HugePage. 但是, 只使用了 4 个 hugepages. 其他的应该在引导后释放. 如果系统内存不足(例如: 64G), 这将是一项不可能完成的任务. 因此, 添加 hugepages_node 内核参数以指定启动时要分配的 hugepages 的节点数. | v1 ☐ 5.14-rc7 | [2021/08/20 PatchWork RFC](https://patchwork.kernel.org/project/linux-mm/patch/20210820030536.25737-1-yaozhenguo1@gmail.com)
*-*-*-*-*-*-*-*
[2021/08/23 PatchWork v1](](https://patchwork.kernel.org/project/linux-mm/patch/20210823130154.75070-1-yaozhenguo1@gmail.com)
*-*-*-*-*-*-*-*
[2021/10/05 PatchWork v8](https://patchwork.kernel.org/project/linux-mm/patch/20211005054729.86457-1-yaozhenguo1@gmail.com) | @@ -2624,7 +2624,7 @@ https://lwn.net/Articles/761118 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/03/25 | Tetsuo Handa | [memcg: killed threads should not invoke memcg OOM killer](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7775face207922ea62a4e96b9cd45abfdc7b9840) | 如果当前线程在等待 oom_lock 时被杀死, 我们不需要调用 memcg OOM Killer | v3 ☐ | [PatchWork](https://patchwork.kernel.org/project/linux-mm/patch/01370f70-e1f6-ebe4-b95e-0df21a0bc15e@i-love.sakura.ne.jp), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7775face207922ea62a4e96b9cd45abfdc7b9840) | -| 2021/10/05 | Vasily Averin | [memcg: prohibit unconditional exceeding the limit of dying tasks](https://patchwork.kernel.org/project/linux-mm/patch/b89715b5-6df7-34a3-f7b9-efa8e0eefd3e@virtuozzo.com) | 内存 cgroup charge 的过程中允许杀死或退出的任务超过硬限制. 假设这些任务占用的内存数量是绑定的, 并且在任务退出时, 大部分内存将被释放. 这类似于任务访问内存储备时的全局 OOM 情况的启发式策略. 在 memcg 水平上没有全局内存短缺, 所以 memcg 启发式比较轻松.
不过, 上述假设过于乐观. 例如:
1. vmalloc 可以扩展到真正大的请求, 启发式将允许这一点. 我们曾经在 vmalloc 分配器中有一个被杀死的任务的早期中断, 但这已经被提交 b8c8a338f75e ("Revert vmalloc: back off when the current task is killed"). 所恢复. 可能还有其他类似的代码路径在分配和充电循环中不检查致命信号.
2. 还有一些内核对象统计到给 memcg, 但是它们没有绑定到进程生命周期. 据观察, 触发这些旁路并造成全球 OOM 情况并非真的很难.
解决这些问题的一种潜在方法是限制过剩的数量(类似于有限房间储备的全局 OOM). 这当然是可能的, 但我们并不清楚需要多少额外的内存, 并且仍然可以防止全局 oom, 因为这将不得不考虑整个 memcg 配置.
这个补丁通过完全删除启发式的策略来解决这个问题. 绕过只允许请求, 要么不能失败, 或失败是不可取的, 而超出应该仍然受到限制. 实现一个被杀死或即将死亡的任务, 如果它已经通过 OOM 杀手阶段, 就不能再被 charge. | v3 ☐ | [LKML](https://lkml.org/lkml/2021/3/25/93) | +| 2021/10/23 | Vasily Averin | [memcg: prohibit unconditional exceeding the limit of dying tasks](https://patchwork.kernel.org/project/linux-mm/patch/b89715b5-6df7-34a3-f7b9-efa8e0eefd3e@virtuozzo.com) | 内存 cgroup charge 的过程中允许杀死或退出的任务超过硬限制. 假设这些任务占用的内存数量是绑定的, 并且在任务退出时, 大部分内存将被释放. 这类似于任务访问内存储备时的全局 OOM 情况的启发式策略. 在 memcg 水平上没有全局内存短缺, 所以 memcg 启发式比较轻松.
不过, 上述假设过于乐观. 例如:
1. vmalloc 可以扩展到真正大的请求, 启发式将允许这一点. 我们曾经在 vmalloc 分配器中有一个被杀死的任务的早期中断, 但这已经被提交 b8c8a338f75e ("Revert vmalloc: back off when the current task is killed"). 所恢复. 可能还有其他类似的代码路径在分配和充电循环中不检查致命信号.
2. 还有一些内核对象统计到给 memcg, 但是它们没有绑定到进程生命周期. 据观察, 触发这些旁路并造成全球 OOM 情况并非真的很难.
解决这些问题的一种潜在方法是限制过剩的数量(类似于有限房间储备的全局 OOM). 这当然是可能的, 但我们并不清楚需要多少额外的内存, 并且仍然可以防止全局 oom, 因为这将不得不考虑整个 memcg 配置.
这个补丁通过完全删除启发式的策略来解决这个问题. 绕过只允许请求, 要么不能失败, 或失败是不可取的, 而超出应该仍然受到限制. 实现一个被杀死或即将死亡的任务, 如果它已经通过 OOM 杀手阶段, 就不能再被 charge. | v3 ☐ | [2021/10/20 PatchWork RFC,0/2](https://patchwork.kernel.org/project/linux-mm/cover/fe1d45a1-276d-b0f4-fb71-8f5c1a9e8872@virtuozzo.com/)
*-*-*-*-*-*-*-*
[2021/10/05 PatchWork v2,0/2](https://patchwork.kernel.org/project/linux-mm/cover/21d79b86-476c-a8f2-e950-2339606f1253@virtuozzo.com)
*-*-*-*-*-*-*-*
[2021/10/20 PatchWork v3,0/2](https://patchwork.kernel.org/project/linux-mm/cover/20e50917-3589-bcb7-0174-b6fccfd15c66@virtuozzo.com) | ## 9.3 KMEMCG @@ -3341,6 +3341,7 @@ DAMON 利用两个核心机制 : **基于区域的采样**和**自适应区域 | 2021/10/13 | Xin Hao | [mm/damon: Adjust the size of kbuf array to avoid overflow](https://patchwork.kernel.org/project/linux-mm/patch/20211013114854.15705-1-xhao@linux.alibaba.com) | NA | v1 ☐ | [PatchWork](https://patchwork.kernel.org/project/linux-mm/patch/20211013114854.15705-1-xhao@linux.alibaba.com) | | 2021/10/16 | Xin Hao | [mm/damon/core: Optimize kdamod.%d thread creation code](https://patchwork.kernel.org/project/linux-mm/patch/20211016165914.96049-1-xhao@linux.alibaba.com) | 当 ctx->adaptive_targets 列表为空, 无需创建并调用kdamond. 只有当 ctx->adaptive_targets 列表不为空, 且 ctx->kdamond 指针为 NULL 时, 才调用__damon_start函数. | v1 ☐ | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/20211016165616.95849-1-xhao@linux.alibaba.com)
*-*-*-*-*-*-*-*
[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/20211016165914.96049-1-xhao@linux.alibaba.com) | | 2021/10/21 | Xin Hao | [mm/damon/dbgfs: Optimize target_ids interface write operation](https://patchwork.kernel.org/project/linux-mm/patch/bc341f48b5558f6816dcef22eca4f4a590efdc67.1634834628.git.xhao@linux.alibaba.com) | NA | v2 ☐ | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/20211021085611.81211-1-xhao@linux.alibaba.com)
*-*-*-*-*-*-*-*
[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/bc341f48b5558f6816dcef22eca4f4a590efdc67.1634834628.git.xhao@linux.alibaba.com) | +| 2021/10/27 | Changbin Du | [mm/damon: simplify stop mechanism](https://patchwork.kernel.org/project/linux-mm/patch/20211027130517.4404-1-changbin.du@gmail.com) | NA | v2 ☐ | [PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/20211027130517.4404-1-changbin.du@gmail.com) | ### 13.4.5 vmstat @@ -3534,6 +3535,7 @@ DAMON 利用两个核心机制 : **基于区域的采样**和**自适应区域 | 2006/01/10 | Christoph Lameter | [Direct Migration V9: Overview](https://lore.kernel.org/patchwork/cover/49754) | NA | v9 ☑ 2.6.16-rc2 | [PatchWork v9,0/5](https://lore.kernel.org/patchwork/cover/49754) | | 2021/08/05 | Christoph Lameter | [Some cleanup for page migration](https://lore.kernel.org/patchwork/cover/1472581) | NA | v1 ☐ | [PatchWork 0/5](https://lore.kernel.org/patchwork/cover/49754) | | 2021/09/22 | John Hubbard | [mm/migrate: de-duplicate migrate_reason strings](https://patchwork.kernel.org/project/linux-mm/patch/20210922041755.141817-2-jhubbard@nvidia.com/) | NA | v1 ☐ | [PatchWork 0/5](https://patchwork.kernel.org/project/linux-mm/patch/20210922041755.141817-2-jhubbard@nvidia.com/) | +| 2021/11/03 | Baolin Wang | [Improve the migration stats](https://patchwork.kernel.org/project/linux-mm/cover/cover.1635936218.git.baolin.wang@linux.alibaba.com) | 根据与 [Zi Yan](https://lore.kernel.org/linux-mm/7E44019D-2A5D-4BA7-B4D5-00D4712F1687@nvidia.com) 的谈话, 这个补丁集改变了 migrate_pages() 的返回值, 以避免返回的数字大于用户通过 move_pages() 系统调用尝试迁移的页面数. 还修复了 trace_mm_compaction_migratepages() 中的 hugetlb 迁移统计和迁移统计. | v1 ☐ | [PatchWork](https://lore.kernel.org/linux-mm/b35e54802a9a82d03d24845b463e9d9a68f7fd6b.1635491660.git.baolin.wang@linux.alibaba.com)
*-*-*-*-*-*-*-*
[PatchWork RFC,0/3](https://patchwork.kernel.org/project/linux-mm/cover/cover.1635936218.git.baolin.wang@linux.alibaba.com) | * numa balancing diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index 7b2e1b9..9e301c8 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -1533,7 +1533,7 @@ PREEMPT-RT PATCH 的核心思想是最小化内核中不可抢占部分的代码 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 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/10/12 | 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 | 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/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) |