diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index 4f62650..21f17cc 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -2280,8 +2280,17 @@ inactive LRU list 应该足够小, 这样 VM 就不需要做太多的工作, 但 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| + +| 2011/05/26 | KAMEZAWA Hiroyuki | [memcg: fix get_scan_count() for small targets](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=246e87a9393448c20873bc5dee64be68ed559e24) | get_scan_count() 中通过 nr_scan_try_batch() 获取将每个区域扫描的页面数量, 这是根据 LRU 的大小和扫确定的 `scan = (anon + file) >> priority.`, 如果 scan < SWAP_CLUSTER_MAX, 这次扫描将被跳过, 并提高优先级. 但是这种策略存在很多问题. 这个补丁移除了 nr_saved_scan[NR_LRU_LISTS], 引入了 force_scan 机制. 如果发现当前优先级下能被扫描的页面很少(scan < SWAP_CLUSTER_MAX), 则但是处于 KSWAPD balancing 和 MEMECG reclaim 等路径, 则使能 force_scan, 强制扫描 SWAP_CLUSTER_MAX 个页面. 从而防止一些 ZONE 区域内因为 LRU 页面很少而无法被回收. | v1 ☑✓ 3.0-rc1 | [LORE](https://lore.kernel.org/lkml/20110427164708.1143395e.kamezawa.hiroyu@jp.fujitsu.com), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=246e87a9393448c20873bc5dee64be68ed559e24) | +| 2011/08/11 | Johannes Weiner | [mm: vmscan: fix force-scanning small targets without swap](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=185efc0f9a1f2d6ad6d4782c5d9e529f3290567f) | 如果系统中没有 SWAP, 匿名页面将不会被扫描. 因此, 当考虑强制扫描一个小目标时, 如果没有 SWAP, 它们不应该被计算在内. 否则, 即使目标的有效扫描数为 0, 且适用其他条件 kswapd/memcg, 也不会强制扫描目标. 因此 force_scan 机制中, 在最开始通过 `scan = (anon + file) >> priority` 就不是非常合适的, 后续处理 force_scan 的时候, 也有判断, 因此移除了开始的这些判断. | v1 ☑✓ v3.1-rc7 | [LORE v1,1/2](https://lore.kernel.org/all/1313094715-31187-1-git-send-email-jweiner@redhat.com), [COMMIT1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a4d3e9e76337059406fcf3ead288c0df22a790e9) | +| 2011/08/11 | Johannes Weiner | [mm: vmscan: drop nr_force_scan[] from get_scan_count](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=f11c0ca501af89fc07b0d9f17531ba3b68a4ef39) | nr_force_scan[] 保存了匿名和文件页的有效扫描号, 以防需要强制扫描且定期计算的扫描号为零. 但是, 有效扫描数总是可以假定为 SWAP_CLUSTER_MAX, 就在将其划分为 anon 和 file 之前. 因此删除这个数组. | v1 ☑✓ v3.2-rc1 | [LORE v1,2/2](https://lore.kernel.org/all/1313094715-31187-1-git-send-email-jweiner@redhat.com), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f11c0ca501af89fc07b0d9f17531ba3b68a4ef39) | | 2014/06/04 | Suleiman Souhlal | [mm: only force scan in reclaim when none of the LRUs arebig enough.](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6f04f48dc9c0433e2bb687f5f7f7af1aba97b04d) | 在此之前, 如果 LRU 大小本身对于当前优先级来说太小, 我们将决定是否在回收过程中[启用 force_scan 强制扫描 LRU].
然而, 这可能会导致文件 LRU 被强制扫描, 即使有很多匿名页面可以回收, 依旧导致了导致热文件页面被不必要地回收.
为了解决这个问题, 我们[只在所有可回收 lru 都不够大的时候强制扫描](https://elixir.bootlin.com/linux/v3.16/source/mm/vmscan.c#L2008). | v1 ☑✓ 3.16-rc1 | [LORE](https://lore.kernel.org/all/alpine.LSU.2.11.1403151957160.21388@eggly.anvils) | +| 2015/01/09 | Vladimir Davydov | [vmscan: force scan offline memory cgroups](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90cbc2508827e1e15dca23361c33cc26dd2b9e99) | commit b2052564e66d ("mm:memcontrol:continue cache Recall from offlined groups") 之后, 在删除 cgroup 时, 不会重新分配向内存 cgroup 收费的页面. 取而代之的是, 它们应该以常规的方式被回收, 以及计入在线内存 cgroup 的页面. 然而, 脱机内存 cgroup 的 lruvec 迟早会变得非常小, 以至于只能以较低的扫描优先级进行扫描(请参见 get_scan_count()). 因此, 如果大型 LRUVEC 中有足够多的可回收页面, 那么离线内存 cgroup 中的页面将永远不会被扫描, 从而浪费内存. 通过无条件地从 kswapd 强制扫描死掉的 LRUVEC 来修复此问题. | v2 ☑✓ 4.0-rc1 | [LORE](https://lore.kernel.org/all/1420790983-20270-1-git-send-email-vdavydov@parallels.com) | | 2015/11/23 | Vladimir Davydov | [vmscan: do not force-scan file lru if its absolute size is small](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=9ee11ba4251dddf1b0e507d184b25b1bd7820773) | 如果系统中有足够的 inactive page cache, 即 !inactive_file_is_low(), 或者说当前实现下就是 inactive FILE LRU 的大小大于 acrtive FILE LRU, 则 [get_scan_count() 中会强制扫描 FILE LRU 忽略 ANON LRU](https://elixir.bootlin.com/linux/v4.4/source/mm/vmscan.c#L2052), 当有大量的 Page Cache 时, 这种逻辑工作得很好. 但如果 FILE LRU 的大小很小(比如只有几 MB), 它就会失败. 在这种情况下 (lru_size >> prio) 趋近于 0(即使使用正常扫描优先级), 此时如果 inactive FILE LRU 的大小大于 acrtive FILE LRU, cgroup 的匿名页面也永远不会被驱逐, 即使好几G的未使用匿名内存, 除非系统经历严重的内存压力. 这对于其他 cgroup 来说是不公平的, 因为它们的工作负载可能是面向 Page Cache 的. 这个补丁试图通过详细 "足够的非活动页面缓存" 检查来修复这个问题: 它不仅检查 `!inactive_file_is_low()`, 还检查当前 cgroup 扫描优先级下能扫描的大小. 如果这些条件不成立, 继续如往常一样 SCAN_FRACT. | v2 ☑✓ 4.5-rc1 | [LORE](https://lore.kernel.org/all/1448275173-10538-1-git-send-email-vdavydov@virtuozzo.com)
*-*-*-*-*-*-*-*
[LORE](https://lore.kernel.org/all/1448275173-10538-1-git-send-email-vdavydov@virtuozzo.com), [关注 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=316bda0e6cc5f36f94b4af8bded16d642c90ad75) | +| 2017/02/28 | Johannes Weiner | [mm: kswapd spinning on unreclaimable nodes - fixes and cleanups](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=491d79ae778f24dbf65f1f2178d4744d940d4093) | Jia 报告了一个场景, 在这个场景中, 一个节点的 kswapd 占用 CPU 100% 并且无限循环. 当前内核当前判断其回收节点的能力(或是否退出并休眠) 的方法是基于扫描的页面数量与可回收的页面数量成比例. 然而, 在 Jia 的场景中, 节点中没有可回收的页面, 并且永远不会满足后退的条件. 这组补丁提供了不基于扫描, 而是基于 kswapd 在 MAX_RECLAIM_RETRIES(16) 连续运行中是否能够实际回收页面, 重新定义了一个不可回收的节点. 这是页面分配器用于放弃直接回收和调用 OOM 杀手的相同标准. 如果它不能释放任何页面, kswapd 将进入休眠状态, 并留下进一步的直接回收调用尝试, 这将取得进展并重新启用 kswapd, 或者调用 OOM 杀死器.
补丁 1 修复了 Jia 所报告的即时问题, 剩下的是更小的补丁, 清理, 以及对旧方法的全面淘汰.
补丁 5/6 是一个例外. 清理了 get_scan_count(). | v1 ☑✓ 4.12-rc1 | [LORE v1,0/9](https://lore.kernel.org/all/20170228214007.5621-1-hannes@cmpxchg.org) | + +[commit 246E87A934 ("memcg: fix get_scan_count() for small targets")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=246e87a9393448c20873bc5dee64be68ed559e24) 试图避免 memcg 的高回收优先级, 方法是在 LRU 中页面较少, 在当前优先级下不会回收任何页面时, 强制其扫描至少扫描 SWAP_CLUSTER_MAX 个页面. 这是在回收决策与优先级挂钩的时候完成的. 如今, 唯一有意义的事情仍然与优先级降到 `DEF_priority - 2` 以下有关, 那就是设置 `laptop_mode=1` 是否通常允许写入. 但在那个时代, 直接回收仍然允许调用 `->writepage()`, 而内核发展至今 kswapd 在扫描系统中的每个干净页面之前都会避免写入. `sc->may_writepage` 即使触发的过于频繁也不会有太大的问题. 因此 [commit ("mm: don't avoid high-priority reclaim on memcg limit reclaim")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=688035f729dcd9a98152c827338805a061f5c6fa) 删除了 force_scan 的内容, 以及它所需要的丑陋的多遍目标计算. + ### 4.2.7.2 Refault Distance 算法 @@ -3616,7 +3625,7 @@ khugepaged 处理流程 |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/05/10 | Muchun Song | [Free some vmemmap pages of HugeTLB page](https://patchwork.kernel.org/project/linux-mm/cover/20210510030027.56044-1-songmuchun@bytedance.com) | HugeTLB 使用的大量 struct page 里面有一部分没啥用可以省略. 复合页中只有头页面(compound_head)中的信息, 剩余尾页面(tail pages)中填充的信息是一样的. 因此一个 2M 的 HugeTLB 在 4K page size 的 x86_64 上会用到 512 个 struct page, 这 512 个 struct page 结构体本身占用了 sizeof(struct page) * 512 / PAGE_SIZE = 8 pages. 所以, 其实可以将最后 7 个 tail pages 的信息有点冗余, 将他们合并为一个页面(将 page 2~7 全部映射到 page 1), 这样只需要实际占用 2 个 page 就完成了映射. 这组补丁节省了大量的内存空间, 当然负面作用是分配和释放的时候会慢个 2 倍, 不过都比较小, MS 级别. | v23 ☑ 5.14-rc1 | [PatchWork v23,0/9](https://patchwork.kernel.org/project/linux-mm/cover/20210510030027.56044-1-songmuchun@bytedance.com) | | 2021/10/18 | Muchun Song | [Free the 2nd vmemmap page associated with each HugeTLB page](https://lore.kernel.org/patchwork/patch/1459641) | NA | v2 ☐ | [2021/07/14 PatchWork RFC](https://patchwork.kernel.org/project/linux-mm/cover/20210714091800.42645-1-songmuchun@bytedance.com)
*-*-*-*-*-*-*-*
[2021/10/18 PatchWork v6,0/5](https://patchwork.kernel.org/project/linux-mm/cover/20211018102043.78685-1-songmuchun@bytedance.com) | -| 2022/02/08 | Muchun Song | [arm64: mm: hugetlb: add support for free vmemmap pages of HugeTLB](https://patchwork.kernel.org/project/linux-mm/patch/20220208054632.66534-1-songmuchun@bytedance.com/) | 612044 | v2 ☐☑ | [PatchWork v2,2/2](https://lore.kernel.org/all/20220208054632.66534-2-songmuchun@bytedance.com) | +| 2022/02/08 | Muchun Song | [arm64: mm: hugetlb: add support for free vmemmap pages of HugeTLB](https://patchwork.kernel.org/project/linux-mm/patch/20220208054632.66534-1-songmuchun@bytedance.com/) | 本系列文章可以极大地减少 2MB HugeTLB 页面的结构页面开销. 与之前的方法相比, 它进一步减少了 2MB HugeTLB 的结构页面开销 12.5%, 这意味着每 1TB HugeTLB 的结构页面开销为 2GB. | v2 ☑ 5.18-rc1 | [PatchWork v2,2/2](https://lore.kernel.org/all/20220208054632.66534-2-songmuchun@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v7,0/5](https://lore.kernel.org/all/20211101031651.75851-1-songmuchun@bytedance.com) | | 2022/02/10 | Joao Martins | [sparse-vmemmap: memory savings for compound devmaps (device-dax)](https://patchwork.kernel.org/project/linux-mm/cover/20220210193345.23628-1-joao.m.martins@oracle.com/) | 这个系列, 通过追求类似于 Muchun Song [Free some vmemmap pages of HugeTLB page](https://patchwork.kernel.org/project/linux-mm/cover/20210510030027.56044-1-songmuchun@bytedance.com) 的方法, 针对带有 compound_pages 的 devmap, 最小化了 struct page 的开销. | v5 ☐☑ | [PatchWork v5,0/5](https://lore.kernel.org/r/20220210193345.23628-1-joao.m.martins@oracle.com) | @@ -4528,7 +4537,7 @@ 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://patchwork.kernel.org/project/linux-mm/cover/20220221084529.1052339-1-ying.huang@intel.com/) | 616201 | v1 ☐☑ | [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://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) | | 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) | diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index deb24f2..b34f33c 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -62,7 +62,9 @@ git log --oneline v5.15...v5.16 | grep -E "Merge tag | Linux " | grep -E "sched | 5.14 | 2021/08/29 | [Merge tag 'sched-core-2021-06-28', 5.14-rc1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=54a728dc5e4feb0a9278ad62b19f34ad21ed0ee4)
[Merge tag 'sched-urgent-2021-06-30', 5.14-rc1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a6eaf3850cb171c328a8b0db6d3c79286a1eba9d)
[Merge tag 'sched-urgent-2021-07-11', 5.14-rc1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=877029d9216dcc842f50d37571f318cd17a30a2d)
[Merge tag 'sched-urgent-2021-08-08', 5.14-rc5](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=713f0f37e8128e8a0190a98f5a4be71fb32a671a)
[Merge tag 'sched_urgent_for_v5.14', 5.14](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=537b57bd5a202af145c266d4773971c2c9f90cd9) | | 5.15 | 2021/11/1 | NA | [Merge tag 'sched-core-2021-08-30'](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d3c0db4598c5de511824649df2aa976259cf10a)
[Merge remote-tracking branch 'tip/sched/arm64'](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=65266a7c6abf)
[Merge tag 'sched_urgent_for_v5.15_rc1'](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=56c244382fdb)
[Merge tag 'sched_urgent_for_v5.15_rc4'](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=777feabaea77)
[Merge tag 'sched_urgent_for_v5.15_rc7'](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6c62666d8879) | 5.16 | 2022/01/09 | [Merge tag 'sched-core-2021-11-01', 5.16-rc1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a7e0a90a454a7826ecbca055a6ec9271b70c686)
[Merge tag 'sched_urgent_for_v5.16_rc1', 5.16-rc3](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc661f2dcb7e)
[Merge tag 'sched-urgent-2021-11-28', 5.16-rc3](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97891bbf38f7)
[Merge tag 'sched_urgent_for_v5.16_rc4', 5.16-rc4](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d213767dc6f)
[Merge tag 'sched-urgent-2021-12-12', 5.16-rc5](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=773602256a2ca73455b0baeae5737c4a9ed6ef49) | -| 5.17 | 2022/03/20 | [sched-core-2021-11-01, 5.16-rc1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9a7e0a90a454a7826ecbca055a6ec9271b70c686)
[sched_urgent_for_v5.16_rc1, 5.16-rc1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc661f2dcb7e41dcda9ae862efb822bb2f461646)
[sched-urgent-2021-11-28, 5.16-rc3](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=97891bbf38f71ec97199d2459368b5b4b700706e)
[sched_urgent_for_v5.16_rc4, 5.16-rc4](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d213767dc6f594022e43b6b59c45e7e3c84c4de)
[sched-urgent-2021-12-1, 5.16-rc5](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=773602256a2ca73455b0baeae5737c4a9ed6ef49) | +| 5.17 | 2022/03/20 | [sched_core_for_v5.17_rc1, 5.17-rc1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ae71436cda7)
[sched_urgent_for_v5.17_rc2, 5.17-rc2](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=10c64a0f2806)
[sched_urgent_for_v5.17_rc2_p2, 5.17-rc2](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f4db1f3a27)
[sched_urgent_for_v5.17_rc4, 5.17-rc4](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6f3573672324)
[sched_urgent_for_v5.17_rc5, 5.17-rc5](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b0894ff78cc) | +| 5.18 | NA | [sched-core-2022-03-22, 5.18-rc1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3fe2f7446f1e029b220f7f650df6d138f91651f2), [scheduler updates for v5.18](https://lore.kernel.org/lkml/YjhZUezhnamHAl0H@gmail.com) | + cgit 上查看 sched 所有的 log 信息 : @@ -1505,7 +1507,7 @@ Oracle 数据库具有类似的虚拟化功能, 称为 Oracle Multitenant, 其 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:----:|:---:|:----------:|:---:| -| 2021/12/01 | Mel Gorman | [Adjust NUMA imbalance for multiple LLCs](https://lore.kernel.org/lkml/20211201151844.20488-1-mgorman@techsingularity.net) | [commit 7d2b5dd0bcc4 ("sched/numa: Allow a floating imbalance between NUMA nodes")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d2b5dd0bcc4) 允许 NUMA 节点之间的不平衡, 这样通信任务不会被 load balance 分开. 当 LLC 和 node 之间有 1:1 的关系时, 这种方法可以很好地工作, 但是对于多个 LLC, 如果独立的任务过早地使用 CPU 共享缓存, 这种方法就不太理想了. 本系列解决了两个问题:
1. 调度程序域权重的使用不一致, 以及当每个 NUMA 节点有许多 LLC 时性能不佳. NUMA之间允许的不均衡的进程数目不再是一个固定的值 NUMA_IMBALANCE_MIN(2), 而是在 build_sched_domains() 中实际探测 NUMA 域下辖的 LLC 的数目, 作为 sd->imb_numa_nr. | v4 ☐ | [PatchWork v3,0/2](https://lore.kernel.org/lkml/20211201151844.20488-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v4,0/2](https://lore.kernel.org/lkml/20211210093307.31701-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v6,0/2](https://lore.kernel.org/all/20220208094334.16379-1-mgorman@techsingularity.net) | +| 2021/12/01 | Mel Gorman | [Adjust NUMA imbalance for multiple LLCs](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e496132ebedd870b67f1f6d2428f9bb9d7ae27fd) | [commit 7d2b5dd0bcc4 ("sched/numa: Allow a floating imbalance between NUMA nodes")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7d2b5dd0bcc4) 允许 NUMA 节点之间的不平衡, 这样通信任务不会被 load balance 分开. 当 LLC 和 node 之间有 1:1 的关系时, 这种方法可以很好地工作, 但是对于多个 LLC, 如果独立的任务过早地使用 CPU 共享缓存, 这种方法就不太理想了. 本系列解决了两个问题:
1. 调度程序域权重的使用不一致, 以及当每个 NUMA 节点有许多 LLC 时性能不佳. NUMA之间允许的不均衡的进程数目不再是一个固定的值 NUMA_IMBALANCE_MIN(2), 而是在 build_sched_domains() 中实际探测 NUMA 域下辖的 LLC 的数目, 作为 sd->imb_numa_nr. | v4 ☑✓ 5.18-rc1 | [PatchWork v3,0/2](https://lore.kernel.org/lkml/20211201151844.20488-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v4,0/2](https://lore.kernel.org/lkml/20211210093307.31701-1-mgorman@techsingularity.net)
*-*-*-*-*-*-*-*
[LORE v6,0/2](https://lore.kernel.org/all/20220208094334.16379-1-mgorman@techsingularity.net) | | 2022/02/17 | K Prateek Nayak | [sched/fair: Consider cpu affinity when allowing NUMA imbalance in find_idlest_group](https://lore.kernel.org/all/20220217055408.28151-1-kprateek.nayak@amd.com) | 当前的调度程序代码只是检查本地组中的任务数是否小于允许的 NUMA 不平衡阈值. 该阈值以前是 NUMA 域跨度的 25%）, 但在 Mel 补丁集 "Adjust NUMA imbalance for multiple LLCs" 中 commit e496132ebedd ("sched/fair: Adjust the allowed NUMA imbalance when SD_NUMA spans multiple LLCs" 现在等于 NUMA 域中的 LLC 数目, 通常情况下这种机制运行良好.
但是对于进程都通过 numactl/taskset PIN 到一组分散的 CPU 上的情况(比如每个 LLC 域中选一个 CPU), 任务的数量将始终在阈值内, 因此所有 8 个流线程将在第一个 SOCKET 上唤醒, 从而导致次优性能. 在最初的少量 CPU 上堆积之后, 虽然负载平衡器可以工作, 但是稳定的均衡状态, 并且需要频繁的迁移 PING PONG.
我们可以通过检查本地组中允许的 CPU 数量是否少于本地组中运行的任务数量来检测并避免这种堆积, 并使用此信息将本来会堆积的县城分散到下一个 SOCKET 中(毕竟, 这个慢路径的目标是在初始放置期间找到最空闲的组和最空闲的 CPU). | v4 ☐☑✓ | [LORE](https://lore.kernel.org/all/20220217055408.28151-1-kprateek.nayak@amd.com) |