diff --git a/distro/Apple/README.md b/distro/Apple/README.md index 9f548f5..16d69dc 100644 --- a/distro/Apple/README.md +++ b/distro/Apple/README.md @@ -130,6 +130,19 @@ xnu-6153.11.26 在 [Mach3.0 中对系统线程所作的一项改进即称为 continuation](https://www.gnu.org/software/hurd/microkernel/mach/gnumach/continuation.html), 其动因恰在于避免保留线程堆栈, 希望使用完全无状态的 continuation 函数.(参见 Uresh Vahalia 的经典著作"UNIX Internals"http://www.china-pub.com/computers/common/info.asp?id=12731). + +# 4 QEMU +------- + +| 工具 | 描述 | +|:---:|:----:| +| [darwinkvm](https://docs.darwinkvm.com) | NA | +| [Booting a macOS Apple Silicon kernel in QEMU](https://worthdoingbadly.com/xnuqemu3) | NA | +| [Darwin VM](http://althenia.net/notes/darwin) | NA | +| [PureDarwin](https://www.puredarwin.org) | NA | +| [Strong ARMing with MacOS: Adventures in Cross-Platform Emulation](https://blogs.blackberry.com/en/2021/05/strong-arming-with-macos-adventures-in-cross-platform-emulation) | NA | + +
* 本作品 / 博文 [成坚 (gatieme) @ 内核干货 (OSKernelLAB)- 紫夜阑珊 - 青伶巷草 Copyright ©2013-2017](http://blog.csdn.net/gatieme) ), 由 [成坚 (gatieme)](http://blog.csdn.net/gatieme) 创作. diff --git a/study/kernel/00-DESCRIPTION/DEBUGGING.md b/study/kernel/00-DESCRIPTION/DEBUGGING.md index 3be6b1b..92cc987 100644 --- a/study/kernel/00-DESCRIPTION/DEBUGGING.md +++ b/study/kernel/00-DESCRIPTION/DEBUGGING.md @@ -543,6 +543,10 @@ x86 和 arm64 都支持直接访问用户空间中的事件计数器. 访问序 | 2022/11/14 | Jiri Slaby (SUSE) | [gcc-LTO support for the kernel](https://lore.kernel.org/all/20221114114344.18650-1-jirislaby@kernel.org) | [Patches Posted For GCC LTO Optimizing The Linux Kernel](https://www.phoronix.com/news/GCC-LTO-Linux-2022) | v1 ☐☑✓ | [LORE v1,00/46](https://lore.kernel.org/all/20221114114344.18650-1-jirislaby@kernel.org) | +其他相关 + +[Unified LTO Bitcode Front-End Comes Together For LLV](https://www.phoronix.com/news/LLVM-Unified-LTO-Front-End). + 4. BOLT'ing @@ -669,6 +673,7 @@ Mesa CI 开始使用 Mold 作为其 x86_64 和 AArch64 上的默认链接器, [Mold 1.6 High Speed Linker Adds PPC64 and s390x, Smaller Output Files](https://www.phoronix.com/news/Mold-1.6-Linker) +[Mold 2.0 High Speed Linker Released: Moves From AGPL To MIT License](https://www.phoronix.com/news/Mold-2.0-Linker) ## 13.9 Compiler Optimization ------- diff --git a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md index 837f351..4898028 100644 --- a/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md +++ b/study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md @@ -261,6 +261,7 @@ Linux 一开始是在一台 i386 上的机器开发的, i386 的硬件页表是 | 2021/01/31 | Nadav Amit | [TLB batching consolidation and enhancements](https://patchwork.kernel.org/project/linux-mm/cover/20210131001132.3368247-1-namit@vmware.com) | TLB 批处理整合和增强. 内核中目前至少有 5 种不同的 TLB 处理方案. 对这种情况做了合并和规整. | v2 ☐ | [PatchWork RFC,00/20](https://patchwork.kernel.org/project/linux-mm/cover/20210131001132.3368247-1-namit@vmware.com) | | 2021/10/21 | Nadav Amit | [mm/mprotect: avoid unnecessary TLB flushes](https://patchwork.kernel.org/project/linux-mm/cover/20211021122112.592634-1-namit@vmware.com) | 用于删除不必要的 TLB 刷新. | v2 ☐ | [2021/09/25 PatchWork v1,0/2](https://patchwork.kernel.org/project/linux-mm/cover/20210925205423.168858-1-namit@vmware.com)
*-*-*-*-*-*-*-*
[2021/10/21 PatchWork v2,0/5](https://patchwork.kernel.org/project/linux-mm/cover/20211021122112.592634-1-namit@vmware.com) | | 2023/04/10 | Huang, Ying | [mm,unmap: avoid flushing TLB in batch if PTE is inaccessible](https://patchwork.kernel.org/project/linux-mm/patch/20230410075224.827740-1-ying.huang@intel.com/) | 738356 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230410075224.827740-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[LORE v1,0/1](https://lore.kernel.org/r/20230424065408.188498-1-ying.huang@intel.com) | +| 2023/08/04 | Byungchul Park | [Reduce TLB flushes under some specific conditions](https://lore.kernel.org/all/20230804061850.21498-1-byungchul@sk.com) | 通过在迁移时保留源和目标作品集来延迟 TLB 刷新. 参见 phoronix 报道 [New Linux Optimization Patches Reduced TLB Flushes By Over 50% In Some Cases](https://www.phoronix.com/news/CXL-TLB-Flushes-50p-Optimize). | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20230804061850.21498-1-byungchul@sk.com)
*-*-*-*-*-*-*-*
[LORE v2,0/6](https://lore.kernel.org/r/20230817080559.43200-1-byungchul@sk.com) | ### 1.3.3 batch TLB flushing @@ -269,7 +270,7 @@ Linux 一开始是在一台 i386 上的机器开发的, i386 的硬件页表是 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2022/09/21 | Huang Ying | [migrate_pages(): batch TLB flushing](https://lore.kernel.org/all/20220921060616.73086-1-ying.huang@intel.com) | 当前, migrate_pages()逐个迁移页面, 对每一页进行解除映射, 刷新 TLB, 然后恢复映射. 如果将多个页面传递给 migrate_pages(), 则有机会批量刷新和复制 TLB. TLB 冲洗 IPI 的总数可以大大减少. 并可以使用一些硬件加速器, 如 DSA 来加速页面复制. 因此, 在这个补丁中, 我们重构了 migrate_pages()实现, 并实现了 TLB 刷新批处理. 在此基础上, 可以实现硬件加速页面复制. 参见 phoronix 报道 [Intel Prepares Linux Batch TLB Flushing For Page Migration As A Big Performance Win](https://www.phoronix.com/news/Linux-Migrate-Pages-Batch-Flush) 和 [Intel Optimization Around Batched TLB Flushing For Folios Looks Great](https://www.phoronix.com/news/Migrate-Pages-Batch-TLB-Flush-F). | v1 ☐☑✓ | [LORE v1,0/6](https://lore.kernel.org/all/20220921060616.73086-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[LORE v1,0/8](https://lore.kernel.org/r/20221227002859.27740-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[LORE v3,0/9](https://lore.kernel.org/all/20230116063057.653862-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[LORE v1,0/9](https://lore.kernel.org/r/20230110075327.590514-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[LORE v1,0/9](https://lore.kernel.org/r/20230206063313.635011-1-ying.huang@intel.com)
*-*-*-*-*-*-*-*
[LORE v1,0/9](https://lore.kernel.org/r/20230213123444.155149-1-ying.huang@intel.com) | -| 2022/10/28 | Yicong Yang | [arm64: support batched/deferred tlb shootdown during page reclamation/migration](https://patchwork.kernel.org/project/linux-mm/cover/20221028081255.19157-1-yangyicong@huawei.com/) | 虽然 ARM64 有硬件进行 tlb shootdown, 但是使用 tlbi 进行硬件广播的开销也不小. 一个最简单的微基准测试显示, 即使在只有 8 核的骁龙 888 上, 即使只分页一个进程映射的页面, ptep_clear_flush() 的开销 (perf top) 也达到了 5.36%. 当页面由多个进程映射或 HW 有更多 CPU 时, 由于 tlb shootdown 糟糕的可伸缩性, 成本应该会变得更高, 同样的基准测试在 100 核左右的 ARM64 服务器上可以导致 16.99% 的 CPU 消耗. 这个补丁集利用现有的 BATCHED_UNMAP_TLB_FLUSH. 只在第一阶段 arch_tlbbatch_add_mm() 中发送 tlbi 指令. 在骁龙 888 上的测试表明, 补丁集消除了 ptep_clear_flush() 的开销. 在骁龙 888 上, 即使是单个进程映射的一个页面, 微基准测试也要快 5%. 有了这个支持, 我们可以对内存回收和[迁移](https://lore.kernel.org/lkml/20220921060616.73086-1-ying.huang@intel.com) 做更多的优化. | v5 ☐☑ | [LORE 0/4](https://lore.kernel.org/lkml/20220707125242.425242-1-21cnbao@gmail.com)
*-*-*-*-*-*-*-*
[LORE v5,0/2](https://lore.kernel.org/r/20221028081255.19157-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v6,0/2](https://lore.kernel.org/r/20221115031425.44640-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v7,0/2](https://lore.kernel.org/r/20221117082648.47526-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v9,0/2](https://lore.kernel.org/r/20230410134352.4519-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v9,0/2](https://lore.kernel.org/r/20230518065934.12877-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v10,0/4](https://lore.kernel.org/r/20230710083914.18336-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v11,0/4](https://lore.kernel.org/r/20230717131004.12662-1-yangyicong@huawei.com) | +| 2022/10/28 | Yicong Yang | [arm64: support batched/deferred tlb shootdown during page reclamation/migration](https://patchwork.kernel.org/project/linux-mm/cover/20221028081255.19157-1-yangyicong@huawei.com/) | 虽然 ARM64 有硬件进行 tlb shootdown, 但是使用 tlbi 进行硬件广播的开销也不小. 一个最简单的微基准测试显示, 即使在只有 8 核的骁龙 888 上, 即使只分页一个进程映射的页面, ptep_clear_flush() 的开销 (perf top) 也达到了 5.36%. 当页面由多个进程映射或 HW 有更多 CPU 时, 由于 tlb shootdown 糟糕的可伸缩性, 成本应该会变得更高, 同样的基准测试在 100 核左右的 ARM64 服务器上可以导致 16.99% 的 CPU 消耗. 这个补丁集利用现有的 BATCHED_UNMAP_TLB_FLUSH. 只在第一阶段 arch_tlbbatch_add_mm() 中发送 tlbi 指令. 在骁龙 888 上的测试表明, 补丁集消除了 ptep_clear_flush() 的开销. 在骁龙 888 上, 即使是单个进程映射的一个页面, 微基准测试也要快 5%. 有了这个支持, 我们可以对内存回收和[迁移](https://lore.kernel.org/lkml/20220921060616.73086-1-ying.huang@intel.com) 做更多的优化. | v5 ☐☑ | [LORE 0/4](https://lore.kernel.org/lkml/20220707125242.425242-1-21cnbao@gmail.com)
*-*-*-*-*-*-*-*
[LORE v5,0/2](https://lore.kernel.org/r/20221028081255.19157-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v6,0/2](https://lore.kernel.org/r/20221115031425.44640-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v7,0/2](https://lore.kernel.org/r/20221117082648.47526-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v8,0/2](https://lore.kernel.org/r/20230329035512.57392-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v9,0/2](https://lore.kernel.org/r/20230410134352.4519-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v9,0/2](https://lore.kernel.org/r/20230518065934.12877-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v10,0/4](https://lore.kernel.org/r/20230710083914.18336-1-yangyicong@huawei.com)
*-*-*-*-*-*-*-*
[LORE v11,0/4](https://lore.kernel.org/r/20230717131004.12662-1-yangyicong@huawei.com) | ## 1.4 [Clarifying memory management with page folios](https://lwn.net/Articles/849538) @@ -351,11 +352,12 @@ Linux 一开始是在一台 i386 上的机器开发的, i386 的硬件页表是 | 2022/11/15 | Sidhartha Kumar | [convert core hugetlb functions to folios](https://patchwork.kernel.org/project/linux-mm/cover/20221115212217.19539-1-sidhartha.kumar@oracle.com/) | 695698 | v1 ☐☑ | [LORE v1,0/10](https://lore.kernel.org/r/20221115212217.19539-1-sidhartha.kumar@oracle.com)
*-*-*-*-*-*-*-*
[LORE v2,0/10](https://lore.kernel.org/r/20221117210258.12732-1-sidhartha.kumar@oracle.com)
*-*-*-*-*-*-*-*
[LORE v3,0/10](https://lore.kernel.org/r/20221117211501.17150-1-sidhartha.kumar@oracle.com)
*-*-*-*-*-*-*-*
[LORE v4,0/10](https://lore.kernel.org/r/20221118222002.82588-1-sidhartha.kumar@oracle.com)
*-*-*-*-*-*-*-*
[LORE v5,0/10](https://lore.kernel.org/r/20221129225039.82257-1-sidhartha.kumar@oracle.com) | | 2022/12/30 | Kefeng Wang | [mm: convert page_idle/damon to use folios](https://patchwork.kernel.org/project/linux-mm/cover/20221230070849.63358-1-wangkefeng.wang@huawei.com/) | 707655 | v4 ☐☑ | [LORE v4,0/8](https://lore.kernel.org/r/20221230070849.63358-1-wangkefeng.wang@huawei.com) | | 2022/12/31 | Matthew Wilcox | [Get rid of first tail page fields](https://patchwork.kernel.org/project/linux-mm/cover/20221231214610.2800682-1-willy@infradead.org/) | 708076 | v1 ☐☑ | [LORE v1,0/22](https://lore.kernel.org/r/20221231214610.2800682-1-willy@infradead.org) | -| 2023/03/17 | Ryan Roberts | [variable-order, large folios for anonymous memory](https://patchwork.kernel.org/project/linux-mm/cover/20230317105802.2634004-1-ryan.roberts@arm.com/) | 731151 | v1 ☐☑ | [LORE v1,0/6](https://lore.kernel.org/r/20230317105802.2634004-1-ryan.roberts@arm.com) | +| 2023/06/26 | Ryan Roberts | [variable-order, large folios for anonymous memory](https://patchwork.kernel.org/project/linux-mm/cover/20230626171430.3167004-1-ryan.roberts@arm.com/) | [Large folios for anonymous memory](https://lwn.net/Articles/937239). | v1 ☐☑ | [LORE v1,0/10](https://lore.kernel.org/r/20230626171430.3167004-1-ryan.roberts@arm.com)
*-*-*-*-*-*-*-*
[LORE v4,0/5](https://lore.kernel.org/r/20230726095146.2826796-1-ryan.roberts@arm.com)
*-*-*-*-*-*-*-*
[LORE v5,0/5](https://lore.kernel.org/r/20230810142942.3169679-1-ryan.roberts@arm.com) | | 2023/04/03 | Zi Yan | [Split a folio to any lower order folios](https://patchwork.kernel.org/project/linux-mm/cover/20230403201839.4097845-1-zi.yan@sent.com/) | 736544 | v3 ☐☑ | [LORE v3,0/7](https://lore.kernel.org/r/20230403201839.4097845-1-zi.yan@sent.com) | | 2023/06/21 | Matthew Wilcox | [Remove pagevecs](https://patchwork.kernel.org/project/linux-mm/cover/20230621164557.3510324-1-willy@infradead.org) | 完成 pagevec 到 folio_batch 的转换. | v1 ☐☑ | [LORE v1,0/13](https://lore.kernel.org/r/20230621164557.3510324-1-willy@infradead.org) | | 2023/07/15 | Matthew Wilcox (Oracle) | [Followup folio conversions for zswap](https://patchwork.kernel.org/project/linux-mm/cover/20230715042343.434588-1-willy@infradead.org/) | 766106 | v1 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20230715042343.434588-1-willy@infradead.org) | | 2023/07/17 | Ryan Roberts | [Optimize large folio interaction with deferred split](https://patchwork.kernel.org/project/linux-mm/cover/20230717143110.260162-1-ryan.roberts@arm.com/) | 766526 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20230717143110.260162-1-ryan.roberts@arm.com)
*-*-*-*-*-*-*-*
[LORE v2,0/3](https://lore.kernel.org/r/20230719135450.545227-1-ryan.roberts@arm.com)
*-*-*-*-*-*-*-*
[LORE v4,0/3](https://lore.kernel.org/r/20230727141837.3386072-1-ryan.roberts@arm.com) | +| 2023/07/28 | Yin, Fengwei | [support large folio for mlock](https://patchwork.kernel.org/project/linux-mm/cover/20230728070929.2487065-1-fengwei.yin@intel.com/) | 770426 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20230728070929.2487065-1-fengwei.yin@intel.com) | @@ -385,7 +387,7 @@ Linux 一开始是在一台 i386 上的机器开发的, i386 的硬件页表是 | 2023/01/05 | Matthew Wilcox | [Split netmem from struct page](https://patchwork.kernel.org/project/linux-mm/cover/20230105214631.3939268-1-willy@infradead.org/) | 709303 | v2 ☐☑ | [LORE v2,0/24](https://lore.kernel.org/r/20230105214631.3939268-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[LORE v3,0/26](https://lore.kernel.org/r/20230111042214.907030-1-willy@infradead.org) | | 2023/02/20 | Hyeonggon Yoo <42.hyeyoo@gmail.com> | [mm/zsmalloc: Split zsdesc from struct page](https://patchwork.kernel.org/project/linux-mm/cover/20230220132218.546369-1-42.hyeyoo@gmail.com/) | 723442 | v1 ☐☑ | [LORE v1,0/25](https://lore.kernel.org/r/20230220132218.546369-1-42.hyeyoo@gmail.com) | | 2022/11/30 | Matthew Wilcox | [Split page pools from struct page](https://patchwork.kernel.org/project/linux-mm/cover/20221130220803.3657490-1-willy@infradead.org/) | 700614 | v1 ☐☑ | [LORE v1,0/24](https://lore.kernel.org/r/20221130220803.3657490-1-willy@infradead.org) | -| 2023/05/01 | Vishal Moola | [Split ptdesc from struct page](https://patchwork.kernel.org/project/linux-mm/cover/20230501192829.17086-1-vishal.moola@gmail.com/) | 参见 LWN 报道 [The proper time to split struct page](https://lwn.net/Articles/937839). | v2 ☐☑ | [LORE v2,0/34](https://lore.kernel.org/r/20230501192829.17086-1-vishal.moola@gmail.com)39268-1-willy@infradead.org/) | 709303 | v2 ☐☑ | [LORE v2,0/24](https://lore.kernel.org/r/20230105214631.3939268-1-willy@infradead.org)[LORE v4,0/34](https://lore.kernel.org/r/20230612210423.18611-1-vishal.moola@gmail.com)
*-*-*-*-*-*-*-*
[LORE v5,0/33](https://lore.kernel.org/r/20230622205745.79707-1-vishal.moola@gmail.com)
*-*-*-*-*-*-*-*
[LORE v7,0/31](https://lore.kernel.org/r/20230725042051.36691-1-vishal.moola@gmail.com) | +| 2023/05/01 | Vishal Moola | [Split ptdesc from struct page](https://patchwork.kernel.org/project/linux-mm/cover/20230501192829.17086-1-vishal.moola@gmail.com/) | 参见 LWN 报道 [The proper time to split struct page](https://lwn.net/Articles/937839). | v2 ☐☑ | [LORE v2,0/34](https://lore.kernel.org/r/20230501192829.17086-1-vishal.moola@gmail.com)39268-1-willy@infradead.org/) | 709303 | v2 ☐☑ | [LORE v2,0/24](https://lore.kernel.org/r/20230105214631.3939268-1-willy@infradead.org)[LORE v4,0/34](https://lore.kernel.org/r/20230612210423.18611-1-vishal.moola@gmail.com)
*-*-*-*-*-*-*-*
[LORE v5,0/33](https://lore.kernel.org/r/20230622205745.79707-1-vishal.moola@gmail.com)
*-*-*-*-*-*-*-*
[LORE v7,0/31](https://lore.kernel.org/r/20230725042051.36691-1-vishal.moola@gmail.com)
*-*-*-*-*-*-*-*
[LORE v8,0/31](https://lore.kernel.org/r/20230731170332.69404-1-vishal.moola@gmail.com)
*-*-*-*-*-*-*-*
[LORE v9,0/31](https://lore.kernel.org/r/20230807230513.102486-1-vishal.moola@gmail.com) | ### 1.4.3 MEMCG Folio @@ -660,7 +662,7 @@ Linux 进程使用不同的虚拟地址空间. 因此, 管理该地址空间状 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2022/11/03 | Muhammad Usama Anjum | [Implement IOCTL to get and optionally clear info about PTEs](https://patchwork.kernel.org/project/linux-mm/cover/20221103100736.2356351-1-usama.anjum@collabora.com/) | 本补丁系列在 procfs 上实现 IOCTL, 以获取关于页表项 (pte) 的信息. 该 ioctl 支持以下操作: 历史上, 软脏 PTE 位跟踪一直用于 CRIU 项目. procfs 接口足以查找软脏位状态, 并清除进程中所有页面的软脏位. 我们有这样的场景, 需要根据需要跟踪特定页面的软脏 PTE 位. 这就需要在进程运行时跟踪和清除内存区域的机制, 以模拟 Windows 的 getWriteWatch()系统调用. 这个系统调用被游戏用来跟踪脏页, 只处理脏页. CRIU 项目需要页面[相关信息, 如果页面是文件映射、呈现和交换的](https://lore.kernel.org/all/20221014134802.1361436-1-mdanylo@google.com). 还需要添加[所需的掩码、任意掩码、排除掩码和返回掩码](https://lore.kernel.org/all/YyiDg79flhWoMDZB@gmail.com). | v4 ☐☑ | [LORE v4,0/3](https://lore.kernel.org/r/20221103100736.2356351-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v6,0/3](https://lore.kernel.org/r/20221109102303.851281-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v12,0/5](https://lore.kernel.org/r/20230406074005.1784728-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v14,0/5](https://lore.kernel.org/r/20230418062008.1434826-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v16,0/5](https://lore.kernel.org/r/20230525085517.281529-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v19,0/5](https://lore.kernel.org/r/20230615141144.665148-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v20,0/5](https://lore.kernel.org/r/20230621072404.2918101-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v21,0/5](https://lore.kernel.org/r/20230626113156.1274521-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v22,0/5](https://lore.kernel.org/r/20230628095426.1886064-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v24,0/5](https://lore.kernel.org/r/20230711125241.1587820-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v26,0/5](https://lore.kernel.org/r/20230727093637.1262110-1-usama.anjum@collabora.com) | +| 2022/11/03 | Muhammad Usama Anjum | [Implement IOCTL to get and optionally clear info about PTEs](https://patchwork.kernel.org/project/linux-mm/cover/20221103100736.2356351-1-usama.anjum@collabora.com/) | 本补丁系列在 procfs 上实现 IOCTL, 以获取关于页表项 (pte) 的信息. 该 ioctl 支持以下操作: 历史上, 软脏 PTE 位跟踪一直用于 CRIU 项目. procfs 接口足以查找软脏位状态, 并清除进程中所有页面的软脏位. 我们有这样的场景, 需要根据需要跟踪特定页面的软脏 PTE 位. 这就需要在进程运行时跟踪和清除内存区域的机制, 以模拟 Windows 的 getWriteWatch()系统调用. 这个系统调用被游戏用来跟踪脏页, 只处理脏页. CRIU 项目需要页面[相关信息, 如果页面是文件映射、呈现和交换的](https://lore.kernel.org/all/20221014134802.1361436-1-mdanylo@google.com). 还需要添加[所需的掩码、任意掩码、排除掩码和返回掩码](https://lore.kernel.org/all/YyiDg79flhWoMDZB@gmail.com). | v4 ☐☑ | [LORE v4,0/3](https://lore.kernel.org/r/20221103100736.2356351-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v6,0/3](https://lore.kernel.org/r/20221109102303.851281-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v12,0/5](https://lore.kernel.org/r/20230406074005.1784728-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v14,0/5](https://lore.kernel.org/r/20230418062008.1434826-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v16,0/5](https://lore.kernel.org/r/20230525085517.281529-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v19,0/5](https://lore.kernel.org/r/20230615141144.665148-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v20,0/5](https://lore.kernel.org/r/20230621072404.2918101-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v21,0/5](https://lore.kernel.org/r/20230626113156.1274521-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v22,0/5](https://lore.kernel.org/r/20230628095426.1886064-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v24,0/5](https://lore.kernel.org/r/20230711125241.1587820-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v26,0/5](https://lore.kernel.org/r/20230727093637.1262110-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v27,0/6](https://lore.kernel.org/r/20230808104309.357852-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v28,0/6](https://lore.kernel.org/r/20230809061603.1969154-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v29,0/6](https://lore.kernel.org/r/20230811180842.3141781-1-usama.anjum@collabora.com)
*-*-*-*-*-*-*-*
[LORE v32,0/6](https://lore.kernel.org/r/20230816113049.1697849-1-usama.anjum@collabora.com) | ### 1.7.8 new page table range API @@ -670,7 +672,7 @@ Linux 进程使用不同的虚拟地址空间. 因此, 管理该地址空间状 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| -| 2023/02/11 | Matthew Wilcox | [New page table range API](https://patchwork.kernel.org/project/linux-mm/cover/20230211033948.891959-1-willy@infradead.org/) | New arch interfaces for manipulating multiple pages | v1 ☐☑ | [LORE v1,0/7](https://lore.kernel.org/r/20230211033948.891959-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[LORE v2,0/30](https://lore.kernel.org/r/20230227175741.71216-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[LORE v3,0/34](https://lore.kernel.org/r/20230228213738.272178-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[LORE v4,0/36](https://lore.kernel.org/r/20230315051444.3229621-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[LORE v1,0/4](https://lore.kernel.org/r/20230530080731.1462122-1-fengwei.yin@intel.com)
*-*-*-*-*-*-*-*
[LORE v5,0/38](https://lore.kernel.org/r/20230710204339.3554919-1-willy@infradead.org) | +| 2023/02/11 | Matthew Wilcox | [New page table range API](https://patchwork.kernel.org/project/linux-mm/cover/20230211033948.891959-1-willy@infradead.org/) | New arch interfaces for manipulating multiple pages | v1 ☐☑ | [LORE v1,0/7](https://lore.kernel.org/r/20230211033948.891959-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[LORE v2,0/30](https://lore.kernel.org/r/20230227175741.71216-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[LORE v3,0/34](https://lore.kernel.org/r/20230228213738.272178-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[LORE v4,0/36](https://lore.kernel.org/r/20230315051444.3229621-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[LORE v1,0/4](https://lore.kernel.org/r/20230530080731.1462122-1-fengwei.yin@intel.com)
*-*-*-*-*-*-*-*
[LORE v5,0/38](https://lore.kernel.org/r/20230710204339.3554919-1-willy@infradead.org)
*-*-*-*-*-*-*-*
[LORE v6,0/38](https://lore.kernel.org/r/20230802151406.3735276-1-willy@infradead.org) | @@ -1759,6 +1761,7 @@ Linux slab 分配器使用了这种思想和其他一些思想来构建一个在 | 2021/08/23 | Vlastimil Babka | [SLUB: reduce irq disabled scope and make it RT compatible](https://lore.kernel.org/patchwork/patch/1469467) | 本系列最初是受到 Mel 的 pcplist local_lock 重写的启发, 同时也对更好地理解 SLUB 的锁以及新的原语、RT 变体和含义感兴趣. 使 SLUB 更有利于抢占, 特别是对于 RT. | v3 ☐ 5.14-rc3 | [PatchWork v3,00/35](https://patchwork.kernel.org/project/linux-mm/cover/20210729132132.19691-1-vbabka@suse.cz)
*-*-*-*-*-*-*-*
[PatchWork v5,00/35](https://patchwork.kernel.org/project/linux-mm/cover/20210823145826.3857-1-vbabka@suse.cz) | | 2021/10/12 | Vlastimil Babka | [mm, slub: change percpu partial accounting from objects to pages](https://patchwork.kernel.org/project/linux-mm/patch/20211012134651.11258-1-vbabka@suse.cz) | NA | v3 ☑ 2.6.22-rc1 | [PatchWork v6](https://lore.kernel.org/patchwork/patch/262225) | | 2022/11/21 | Vlastimil Babka | [Introduce CONFIG_SLUB_TINY and deprecate SLOB](https://patchwork.kernel.org/project/linux-mm/cover/20221121171202.22080-1-vbabka@suse.cz/)| 697743 | v1 ☐☑ | [LORE v1,0/12](https://lore.kernel.org/r/20221121171202.22080-1-vbabka@suse.cz) | +| 2023/08/08 | Vlastimil Babka | [SLUB percpu array caches and maple tree nodes](https://patchwork.kernel.org/project/linux-mm/cover/20230808095342.12637-7-vbabka@suse.cz/) | 773975 | v1 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20230808095342.12637-7-vbabka@suse.cz)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/r/20230810163627.6206-9-vbabka@suse.cz) | SLUB 这是第二个对象分配器实现. 引入这个新的实现的原因是 SLAB 存在的一些问题. 比如 NUMA 的支持, SLAB 引入时内核还没支持 NUMA, 因此, 一开始就没把 NUMA 的需求放在设计理念里, 结果导致后来的对 NUMA 的支持比较臃肿奇怪, 一个典型的问题是, SLAB 为追踪这些缓存, 在每个 CPU, 每个 node, 上都维护着对象队列. 同时, 为了满足 NUMA 分配的局部性, 每个 node 上还维护着所有其他 node 上的队列, 这样导致 SLAB 内部为维护这些队列就得花费大量的内存空间, 并且是 O(n^2) 级别的. 这在大规模的 NUMA 机器上, 浪费的内存相当可观. 同时, 还有别的一些使用上的问题, 导致开发者对其不满, 因而引入了新的实现. 参见 [The SLUB allocator](https://lwn.net/Articles/229984). @@ -3976,7 +3979,8 @@ v2.5 的时候引入了 shrink 机制, 并提供了 API 统一了各个模块的 | 2018/08/07 | Kirill Tkhai | [Introduce lockless shrink_slab()](https://patchwork.kernel.org/project/linux-mm/cover/153365347929.19074.12509495712735843805.stgit@localhost.localdomain) | NA | RFC ☐ | [LORE v8,00/17](https://patchwork.kernel.org/project/linux-mm/cover/153365347929.19074.12509495712735843805.stgit@localhost.localdomain) | | 2022/04/02 | Hillf Danton | [[RFC] mm/vmscan: add periodic slab shrinker](https://patchwork.kernel.org/project/linux-mm/patch/20220402072103.5140-1-hdanton@sina.com/) | 当一个具有大量内存的系统在一个目录中有数百万个 negative dentries 时, 在添加 inotify watch 时可能[会发生 softlookup](https://lore.kernel.org/linux-fsdevel/20220209231406.187668-1-stephen.s.brennan@oracle.com). 为了解决这个问题可以添加独立于直接回收和后台回收运行的周期性(periodic) slab shrinker, 以回收已冷却 30 秒以上的 slab 对象. 向 shrink 控件添加 periodic flag, 让缓存所有者知道这是一个周期性收缩器, 它与以最低 recalim 优先级运行的常规 shrinker 相同, 并且可以在没有一次性对象的情况下随意执行任何操作. | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220402072103.5140-1-hdanton@sina.com) | | 2023/02/20 | Qi Zheng | [make slab shrink lockless](https://patchwork.kernel.org/project/linux-mm/cover/20230220091637.64865-1-zhengqi.arch@bytedance.com/) | 723376 | v1 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20230220091637.64865-1-zhengqi.arch@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v2,0/7](https://lore.kernel.org/r/20230223132725.11685-1-zhengqi.arch@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v3,0/8](https://lore.kernel.org/r/20230226144655.79778-1-zhengqi.arch@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v4,0/8](https://lore.kernel.org/all/20230307065605.58209-1-zhengqi.arch@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v5,0/8](https://lore.kernel.org/r/20230313112819.38938-1-zhengqi.arch@bytedance.com) | - +| 2023/06/22 | Qi Zheng | [use refcount+RCU method to implement lockless slab shrink](https://patchwork.kernel.org/project/linux-mm/cover/20230622085335.77010-1-zhengqi.arch@bytedance.com/) | 759412 | v1 ☐☑ | [LORE v1,0/29](https://lore.kernel.org/r/20230622085335.77010-1-zhengqi.arch@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v2,0/47](https://lore.kernel.org/r/20230724094354.90817-1-zhengqi.arch@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v3,0/49](https://lore.kernel.org/r/20230727080502.77895-1-zhengqi.arch@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v4,0/48](https://lore.kernel.org/r/20230807110936.21819-1-zhengqi.arch@bytedance.com) | +| 2023/08/16 | Qi Zheng | [use refcount+RCU method to implement lockless slab shrink (part 1)](https://patchwork.kernel.org/project/linux-mm/cover/20230816083419.41088-1-zhengqi.arch@bytedance.com/) | 776546 | v1 ☐☑ | [LORE v1,0/5](https://lore.kernel.org/r/20230816083419.41088-1-zhengqi.arch@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v2,0/5](https://lore.kernel.org/r/20230817112402.77010-1-zhengqi.arch@bytedance.com) | ### 4.3.3 THP Shrinker ------- @@ -5524,6 +5528,7 @@ mcpage 有成本. 除了 THP 没有带来 TLB 的好处之外, 与 4K 基本页 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2022/05/16 | Jakub Matěna | [Removing limitations of merging anonymous VMAs](https://patchwork.kernel.org/project/linux-mm/cover/20220218122019.130274-1-matenajakub@gmail.com/) | [Anonymous VMA merging improvements WIP](https://people.kernel.org/vbabka/anonymous-vma-merging-improvements-wip) | v1 ☐☑ | [2022/02/18 LORE v1,0/4](https://lore.kernel.org/r/20220218122019.130274-1-matenajakub@gmail.com)
*-*-*-*-*-*-*-*
[2022/05/16 LORE v3,0/6](https://lore.kernel.org/r/20220516125405.1675-1-matenajakub@gmail.com) | +| 2023/07/28 | Muhammad Usama Anjum | [WIP: Performance improvements](https://patchwork.kernel.org/project/linux-mm/patch/6b6a4e1c-a9e9-9592-d5b4-3c9210c8b650@collabora.com/) | 770530 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/6b6a4e1c-a9e9-9592-d5b4-3c9210c8b650@collabora.com) | ## 8.2 Page Fault @@ -5770,7 +5775,12 @@ Dirty COW(CVE-2016-5195) 是近几年影响比较严重的问题, 参见 [Dirty #### 8.2.5.4 Per-VMA locks ------- -参见 LWN 报道 [Concurrent page-fault handling with per-VMA locks](https://lwn.net/Articles/906852) +参见 LWN 报道: + +[Concurrent page-fault handling with per-VMA locks](https://lwn.net/Articles/906852) + +[Stabilizing per-VMA locking](https://lwn.net/Articles/937943) + 2022 年, LSF/MM 在 [SPF](https://lore.kernel.org/all/20220128131006.67712-1-michel@lespinasse.org) 讨论中讨论了 Per-VMA locks 的想法, 该想法的结论是: 可以 rw_semaphore 放入 VMA 本身; 这将产生使用 VMA 作为一种锁范围的效果. @@ -5805,6 +5815,7 @@ VMA 的读锁定是使用两个序列号完成的: 一个在 vm_area_struct 中, | 2023/07/04 | Suren Baghdasaryan | [[1/1] fork: lock VMAs of the parent process when forking](https://patchwork.kernel.org/project/linux-mm/patch/20230704200656.2526715-1-surenb@google.com/) | 762467 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230704200656.2526715-1-surenb@google.com) | | 2023/07/05 | Suren Baghdasaryan | [Avoid memory corruption caused by per-VMA locks](https://patchwork.kernel.org/project/linux-mm/cover/20230705063711.2670599-1-surenb@google.com/) | 762531 | v2 ☐☑ | [LORE v2,0/2](https://lore.kernel.org/r/20230705063711.2670599-1-surenb@google.com)
*-*-*-*-*-*-*-*
[LORE v3,0/2](https://lore.kernel.org/r/20230705171213.2843068-1-surenb@google.com)
*-*-*-*-*-*-*-*
[LORE v4,0/2](https://lore.kernel.org/r/20230706011400.2949242-1-surenb@google.com) | | 2023/07/24 | Matthew Wilcox (Oracle) | [Handle most file-backed faults under the VMA lock](https://patchwork.kernel.org/project/linux-mm/cover/20230724185410.1124082-1-willy@infradead.org/) | 769002 | v3 ☐☑ | [LORE v3,0/10](https://lore.kernel.org/r/20230724185410.1124082-1-willy@infradead.org) | +| 2023/07/31 | Suren Baghdasaryan | [make vma locking more obvious](https://patchwork.kernel.org/project/linux-mm/cover/20230731171233.1098105-1-surenb@google.com/) | 771308 | v1 ☐☑ | [LORE v1,0/6](https://lore.kernel.org/r/20230731171233.1098105-1-surenb@google.com) | #### 8.2.5.5 Maple Tree @@ -6677,6 +6688,7 @@ Intel 的吴峰光 [PMEM NUMA node and hotness accounting/migration](https://lor | 2022/10/20 | Huang, Ying | [memory tier, sysfs: rename attribute"nodes"to"nodelist"](https://patchwork.kernel.org/project/linux-mm/patch/20221020015122.290097-1-ying.huang@intel.com/) | 686946 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20221020015122.290097-1-ying.huang@intel.com) | | 2022/11/22 | Mina Almasry | [[RFC,V1] mm: Disable demotion from proactive reclaim](https://patchwork.kernel.org/project/linux-mm/patch/20221122203850.2765015-1-almasrymina@google.com/) | 698228 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20221122203850.2765015-1-almasrymina@google.com) | | 2022/11/22 | Mina Almasry | [mm: Add memory.demote for proactive demotion only](https://patchwork.kernel.org/project/linux-mm/patch/20221122203850.2765015-2-almasrymina@google.com/) | 添加主动降级接口 memory.demote.
此接口可按如下方式使用:
`echo "1m" > memory.demote`. 在这个命令下, 内核将尝试从这个 cgroup 中降级 1M 的内存. 内核可能无法降级用户空间请求的全部数量, 在这种情况下, EAGAIN 将返回给用户(类似于 memory.request). 内核将只尝试使用此接口降级页面. 它不会尝试任何其他类型的回收(交换、写回或回收干净的文件页). | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20221122203850.2765015-2-almasrymina@google.com) | +| 2023/08/16 | Huang, Ying | [memory tiering: calculate abstract distance based on ACPI HMAT](https://patchwork.kernel.org/project/linux-mm/cover/20230816080024.105554-1-ying.huang@intel.com/) | 我们有明确的内存层框架来管理具有多种类型内存的系统, 例如 DIMM 插槽中的 DRAM 和 CXL 内存设备. 其中, 相同类型的内存设备将被分组为内存类型, 然后放入内存层中. 为了描述内存类型的性能, 定义了抽象距离. 这与内存延迟成正比, 与内存带宽成反比. 为了使代码尽可能简单, dax/kmem 中使用固定的抽象距离来描述慢速内存, 例如 Optane DCPMM.
为了支持更多的内存类型, 在本系列中, 添加了抽象距离计算算法管理机制, 提供了基于 ACPI HMAT 的算法实现, 并在 dax/kmem 驱动程序中使用了通用的抽象距离计算接口. 因此, dax/kmem 除了原始的 Optane DCPMM 之外, 还可以支持 HBM(高带宽内存). | v1 ☐☑ | [LORE v1,0/4](https://lore.kernel.org/r/20230816080024.105554-1-ying.huang@intel.com) | @@ -7282,6 +7294,15 @@ PLRUS 这一机制旨在解决与 MGLRU 工作类似的问题, MGLRU 也试图 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2022/11/24 | SeongJae Park | [implement DAMOS filtering for anon pages and](https://patchwork.kernel.org/project/linux-mm/cover/20221124212114.136863-1-sj@kernel.org/) | 698964 | v1 ☐☑ | [LORE v1,0/11](https://lore.kernel.org/r/20221124212114.136863-1-sj@kernel.org)
*-*-*-*-*-*-*-*
[LORE v1,0/11](https://lore.kernel.org/r/20221205230830.144349-1-sj@kernel.org) | +| 2023/08/02 | SeongJae Park | [Extedn DAMOS filters for address ranges and DAMON monitoring targets](https://patchwork.kernel.org/project/linux-mm/cover/20230802214312.110532-1-sj@kernel.org/) | 772342 | v1 ☐☑ | [LORE v1,0/13](https://lore.kernel.org/r/20230802214312.110532-1-sj@kernel.org) | + + +#### 13.6.4.3 DAMOS VM +------- + +| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | +|:----:|:----:|:---:|:----:|:---------:|:----:| +| 2023/08/01 | Sudarshan Rajagopalan | [vmrd: dynamic guest VM memory resizing daemon](https://patchwork.kernel.org/project/linux-mm/cover/cover.1690836010.git.quic_sudaraja@quicinc.com/) | 771831 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/cover.1690836010.git.quic_sudaraja@quicinc.com) | ### 13.6.5 业界的使用 @@ -7345,6 +7366,8 @@ CSDN 宣传博客 [内存不超过 5M, datop 在识别冷热内存及跨 numa | 2023/04/06 | Stefan Roesch | [mm: process/cgroup ksm support](https://patchwork.kernel.org/project/linux-mm/cover/20230123173748.1734238-1-shr@devkernel.io/) | 到目前为止, KSM 只能通过为内存区域调用 madvise 来启用. 这组补丁允许在进程 / cgroup 级别启用/禁用 KSM. 参见 [Process-level kernel samepage merging control](https://lwn.net/Articles/928510) | v1 ☐☑ | [LORE v1,0/20](https://lore.kernel.org/r/20230123173748.1734238-1-shr@devkernel.io)
*-*-*-*-*-*-*-*
[LORE v2,0/19](https://lore.kernel.org/r/20230210215023.2740545-1-shr@devkernel.io)
*-*-*-*-*-*-*-*
[LORE v3,0/3](https://lore.kernel.org/r/20230224044000.3084046-1-shr@devkernel.io)
*-*-*-*-*-*-*-*
[LORE v4,0/3](https://lore.kernel.org/all/20230310182851.2579138-1-shr@devkernel.io)
*-*-*-*-*-*-*-*
[LORE v5,0/3](http://lore.kernel.org/all/20230406165339.1017597-1-shr@devkernel.io)
*-*-*-*-*-*-*-*
[LORE v5,0/3](https://lore.kernel.org/r/20230406165339.1017597-1-shr@devkernel.io)
*-*-*-*-*-*-*-*
[LORE v7,0/3](https://lore.kernel.org/r/20230413233115.1878303-1-shr@devkernel.io)
*-*-*-*-*-*-*-*
[LORE v8,0/3](https://lore.kernel.org/r/20230415225913.3206647-1-shr@devkernel.io)
*-*-*-*-*-*-*-*
[LORE v9,0/3](https://lore.kernel.org/r/20230418051342.1919757-1-shr@devkernel.io) | | 2023/02/10 | Stefan Roesch | [[v1] mm: add tracepoints to ksm](https://patchwork.kernel.org/project/linux-mm/patch/20230210214645.2720847-1-shr@devkernel.io/) | 720845 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230210214645.2720847-1-shr@devkernel.io)
*-*-*-*-*-*-*-*
[LORE v2,0/1](https://lore.kernel.org/r/20230313204606.3581988-1-shr@devkernel.io) | | 2023/02/27 | Stefan Roesch | [[v1] prctl: add flags to enable KSM at the process level](https://patchwork.kernel.org/project/linux-mm/patch/20230227220206.436662-1-shr@devkernel.io/) | 725338 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230227220206.436662-1-shr@devkernel.io) | +| 2023/08/11 | Stefan Roesch | [[mm/ksm: add pages scanned metric](https://patchwork.kernel.org/project/linux-mm/patch/20230811193655.2518943-1-shr@devkernel.io/) | 775482 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230811193655.2518943-1-shr@devkernel.io) | +| 2023/08/17 | Stefan Roesch | [proc/ksm: add ksm stats to /proc/pid/smaps](https://patchwork.kernel.org/project/linux-mm/patch/20230817162301.3472457-1-shr@devkernel.io/) | 777100 | v3 ☐☑ | [LORE v3,0/1](https://lore.kernel.org/r/20230817162301.3472457-1-shr@devkernel.io) | ## 14.2 HWPoison - 内存页错误的处理 @@ -7537,6 +7560,7 @@ OS 判断如果是在用户态触发这个硬件内存错误时, 处理方式是 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:-----:|:----:|:----:|:----:|:------------:|:----:| | 2022/01/30 | Edgecombe, Rick P | [Shadow stacks for userspace](https://patchwork.kernel.org/project/linux-mm/cover/20220130211838.8382-1-rick.p.edgecombe@intel.com) | [User-space shadow stacks (maybe) for 6.4](https://lwn.net/Articles/926649). | v1 ☐☑ | [PatchWork v1,0/35](https://lore.kernel.org/r/20220130211838.8382-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v2,0/39](https://lore.kernel.org/r/20220929222936.14584-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v3,0/37](https://lore.kernel.org/r/20221104223604.29615-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v4,0/39](https://lore.kernel.org/r/20221203003606.6838-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v5,0/39](https://lore.kernel.org/r/20230119212317.8324-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v6,0/41](https://lore.kernel.org/r/20230218211433.26859-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v7,0/41](https://lore.kernel.org/r/20230227222957.24501-1-rick.p.edgecombe@intel.com)
*-*-*-*-*-*-*-*
[LORE v8,0/40](https://lore.kernel.org/r/20230319001535.23210-1-rick.p.edgecombe@intel.com) | +| 2023/07/16 | Mark Brown | [arm64/gcs: Provide support for GCS in userspace](https://lore.kernel.org/all/20230716-arm64-gcs-v1-0-bf567f93bba6@kernel.org) | 影子堆栈的 64 位 Arm 实现称为"受保护的控制堆栈"("guarded control stack/GCS), 参见 LWN 报道 [Shadow stacks for 64-bit Arm systems](https://lwn.net/Articles/940403). | v1 ☐☑✓ | [LORE v1,0/35](https://lore.kernel.org/all/20230716-arm64-gcs-v1-0-bf567f93bba6@kernel.org)
*-*-*-*-*-*-*-*
[LORE v3,0/36](https://lore.kernel.org/all/20230731-arm64-gcs-v3-0-cddf9f980d98@kernel.org)
*-*-*-*-*-*-*-*
[LORE v4,0/36](https://lore.kernel.org/r/20230807-arm64-gcs-v4-0-68cfa37f9069@kernel.org) | diff --git a/study/kernel/00-DESCRIPTION/SCHEDULER.md b/study/kernel/00-DESCRIPTION/SCHEDULER.md index 023be0a..552ea30 100644 --- a/study/kernel/00-DESCRIPTION/SCHEDULER.md +++ b/study/kernel/00-DESCRIPTION/SCHEDULER.md @@ -518,6 +518,7 @@ linux 调度器定义了多个调度类, 不同调度类的调度优先级不同 | 2019/12/19 | Kirill Tkhai | [sched: Micro optimization in pick_next_task() and in check_preempt_curr()](https://lore.kernel.org/patchwork/cover/1170294) | 在二进制中通过 xxx_sched_class 地址顺序标记调度类的优先级, 从而可以通过直接比较两个 xxx_sched_class 地址的方式, 优化调度器中两个热点函数 pick_next_task() 和 check_preempt_curr(). | v2 ☐ |[PatchWork RFC](https://lore.kernel.org/patchwork/cover/1170249)
*-*-*-*-*-*-*-*
[PatchWork v2](https://lore.kernel.org/patchwork/cover/1170294) | | 2019/12/19 | Steven Rostedt | [sched: Optimizations to sched_class processing](https://lore.kernel.org/patchwork/cover/1170901) | 对上面补丁的进一步优化, 对齐数据结构保证 cache 对齐, 通过链接脚本保证数据的排布顺序. | RFC ☑ 5.9-rc1 | [PatchWork](https://lore.kernel.org/patchwork/cover/1170901) | + 这组补丁在 5.9-rc1 时合入主线, 至此, 我们可以 [直接在调度器中通过比较地址高低, 直接判断两个调度类的优先级](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aa93cd53bc1b91b5f99c7b55e3dcc1ac98e99558). 当然这组补丁还有个附带的好处, 就是 `kernel/sched/core.o` 的二进制体积更小了. 从这组补丁可以看出来, 调度器中的算法和数据结构对性能简直到了吹毛求疵的地步, 这里也不得不佩服社区调度和性能大神的脑洞和技术能力. @@ -573,6 +574,9 @@ linux 调度器定义了多个调度类, 不同调度类的调度优先级不同 | 2011/12/15 | Peter Zijlstra | [sched: Avoid SMT siblings in select_idle_sibling() if possible](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4dcfe1025b513c2c1da5bf5586adb0e80148f612) | 如果有共享缓存的空闲核心, 避免 select_idle_sibling() 选择兄弟线程. | v1 ☑✓ 3.2-rc5 | [PatchWork v1](https://lore.kernel.org/lkml/1321350377.1421.55.camel@twins) | | 2020/10/23 | Josh Don | [sched: better handling for busy polling loops](https://lore.kernel.org/all/20201023032944.399861-1-joshdon@google.com) | 20201023032944.399861-1-joshdon@google.com | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20201023032944.399861-1-joshdon@google.com) | | 2021/11/16 | Peng Wang | [Add busy loop polling for idle SMT](https://lore.kernel.org/all/cover.1637062971.git.rocking@linux.alibaba.com) | SMT 级别的忙轮询等待. 当启用硬件 SMT 时, 在一个 CPU 的空闲和忙碌状态之间切换将导致同一核心上的同级 CPU 的性能波动. 在一个 SMT CPU 上需要稳定的性能时, 无论同一核心上的同级 CPU 是否空闲, 都需要一致的反馈, 而不期望有噪音. 原始 cpu_idle_force_poll 使用 cpu_relax() 等待被 IPI 唤醒, 而此 smt_idle_force_poll 使用忙循环来提供一致的 SMT 管道干扰. 可以使用 cgroup 的 cpu.smt_idle_poll 为特定任务配置启用忙循环轮询. | v1 ☐ | [PatchWork v1](https://lore.kernel.org/all/cover.1637062971.git.rocking@linux.alibaba.com) | +| 2023/07/20 | Kenan.Liu | [Adjust CFS loadbalance to adapt QEMU CPU topology.](https://lore.kernel.org/all/1689842053-5291-1-git-send-email-Kenan.Liu@linux.alibaba.com) | 使用 Qemu 的 VM 中的多线程工作负载可能会遇到意外现象: 物理核心的一个超线程繁忙, 而其同级处于空闲状态. 主要原因是 qemu 原生 x86 CPU 型号中的超线程索引是连续的, 这与物理拓扑不同. 作为当前的内核调度程序实现, 在负载平衡和负载部署期间, 具有偶数 ID 号的超线程将以更高的概率被拾取. 此 RFC 旨在通过调整 CFS 负载平衡策略来解决此问题:
1. 探索 CPU 拓扑, 并在发现具有 qemu 本机 CPU 拓扑的机器时调整 CFS 负载均衡策略.
2. 导出 procfs 以控制选择空闲 CPU 时的遍历长度. 参见 [Alibaba Eyes Linux CPU Scheduler Changes To Better Handle QEMU With SMT/HT Threads](https://www.phoronix.com/news/Linux-Sched-QEMU-SMT-Better). | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/1689842053-5291-1-git-send-email-Kenan.Liu@linux.alibaba.com) | +| 2023/07/05 | Laurent Dufour | [Introduce SMT level and add PowerPC support](https://lore.kernel.org/all/20230705145143.40545-1-ldufour@linux.ibm.com) | [Linux 6.6 To Make It Easier To Enable Partial SMT For POWER](https://www.phoronix.com/news/Linux-6.6-Partial-SMT-Control). | v4 ☐☑✓ | [LORE v4,0/10](https://lore.kernel.org/all/20230705145143.40545-1-ldufour@linux.ibm.com) | + #### 1.5.4.2 SMT scheduling/core scheduling vs coscheduling ------- @@ -952,7 +956,7 @@ v3.8 合入了 [LWN-2013/01/29, Per-entity load tracking](https://lwn.net/Articl |:----:|:----:|:---:|:----:|:---------:|:----:| | 2012/08/23 | pjt@google.com | [sched: per-entity load-tracking](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=e9c84cb8d5f1b1ea6fcbe6190d51dc84b6975938) | PELT | v1 ☐☑✓ | [LORE v1,0/16](https://lore.kernel.org/all/20120823141422.444396696@google.com) | | 2018/04/09 | Patrick Bellasi | [sched/fair: add support to tune PELT ramp/decay timings](https://lore.kernel.org/all/20180409165134.707-1-patrick.bellasi@arm.com) | 内核支持不同的 PELT 半衰期设置, 通过 CONFIG_PELT_HALFLIFE_32/CONFIG_PELT_HALFLIFE_16/CONFIG_PELT_HALFLIFE_8 选择. | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20180409165134.707-1-patrick.bellasi@arm.com) | -| 2022/08/29 | Dietmar Eggemann | [sched/pelt: Change PELT halflife at runtime](https://lore.kernel.org/all/20220829055450.1703092-1-dietmar.eggemann@arm.com) | 允许系统运行时设置 PELT 的半衰期. 新的 sysctl sched_pelt_multiplier 允许用户将时钟乘数设置为 x1, x2 或 x4. 该时钟倍增器 (clock multiplier artificially) 加速 PELT 斜坡上升 / 下降, 它将影响 PELT 的半衰期 (x1 对应 32ms, x2 对应 16ms, x3 对应 8ms). | v1 ☐☑✓ | [LORE v1,1/1](https://lore.kernel.org/all/20220829055450.1703092-2-dietmar.eggemann@arm.com) | +| 2022/08/29 | Dietmar Eggemann | [sched/pelt: Change PELT halflife at runtime](https://lore.kernel.org/all/20220829055450.1703092-1-dietmar.eggemann@arm.com) | [sched/pelt: Introduce PELT multiplier](https://lore.kernel.org/all/20220829055450.1703092-1-dietmar.eggemann@arm.com) 允许系统运行时设置 PELT 的半衰期. 新的 sysctl sched_pelt_multiplier 允许用户将时钟乘数设置为 x1, x2 或 x4. 该时钟倍增器 (clock multiplier artificially) 加速 PELT 斜坡上升 / 下降, 它将影响 PELT 的半衰期 (x1 对应 32ms, x2 对应 16ms, x3 对应 8ms). | v1 ☐☑✓ | [LORE v1,1/1](https://lore.kernel.org/all/20220829055450.1703092-2-dietmar.eggemann@arm.com) | | 扩展资料 | 描述 | |:-------:|:---:| @@ -4380,6 +4384,7 @@ Donnefort 称: 边距删除使内核能够充分利用能量模型, 任务更有 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:---:|:----------:|:----:| | 2022/06/21 | Vincent Donnefort | [feec() energy margin removal](https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?id=b812fc9768e0048582c8e18d7b66559c1758dde1) | feec() 将迁移任务以节省能源, 前提是它至少节省了系统消耗的总能源的 6%. 这种保守的方法对于终端来说是一个问题, 在这个系统中, 许多小任务会在总体上产生巨大的负载: 很少有任务可以迁移到较小的 CPU, 这会浪费大量的能量. 与其试图确定另一个裕度, 不如尝试删除它. | v11 ☐☑✓ | [LORE v11,0/7](https://lore.kernel.org/all/20220621090414.433602-1-vdonnefort@google.com) | +| 2023/08/28 | Qais Yousef | [sched: cpufreq: Remove magic margins](https://lore.kernel.org/all/20230827233203.1315953-1-qyousef@layalina.io) | TODO | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20230827233203.1315953-1-qyousef@layalina.io) | #### 7.2.3.4 feec improvement ------- @@ -5169,6 +5174,8 @@ CPUFreq 驱动是处理和平台相关的逻辑, Governor 中实现了具体的 |:----:|:----:|:---:|:----------:|:---:| | 2021/08/12 | Viresh Kumar | [Add callback to register with energy model](https://lore.kernel.org/patchwork/cover/1424708) | 当前许多 cpufreq 驱动程序向每个策略的注册了能耗模型, 并通过相同的操作 dev_pm_opp_of_register_em() 来完成. 但是随着 thermal-cooling 的完善, 可以在 cpufreq 层次通过新的回调 register_em 来完成这个工作. | v3 ☐ | [PatchWork V3,0/9](https://patchwork.kernel.org/project/linux-arm-kernel/cover/cover.1628742634.git.viresh.kumar@linaro.org) | | 2021/09/08| Viresh Kumar | [Inefficient OPPs](https://patchwork.kernel.org/project/linux-pm/cover/1631109930-290049-1-git-send-email-vincent.donnefort@arm.com) | schedutil 中增加了对低能效 (inefficient) OPP 的感知, 引入 CPUFREQ_RELATION_E 标记来使得 CPUFREQ 只使用和引用有效的频点.
Arm 的 Power 团队在为谷歌的 Pixel4 开发一个实验性内核, 以评估和改进现实生活中 Android 设备上的主线性能和能耗. 发现 SD855 SoC 有几个效率低下的 OPP. 这些 OPP 尽管频率较低, 但功耗却较高, 任务这种频率下工作, 性能不光下降了, 功耗也很高. 通过将它们从 EAS 能效模型中移除, 使得最高效的 CPU 在任务分配上更有吸引力, 有助于减少中、大型 CPU 的运行时间, 同时提高了集群的空闲时间. 由于集群之间存在巨大的能源成本差异, 因此增加空闲时间对该平台来说至关重要. | v7 ☑ 5.16-rc1 | [PatchWork v7,0/9](https://patchwork.kernel.org/project/linux-pm/cover/1631109930-290049-1-git-send-email-vincent.donnefort@arm.com) | +| 2023/07/24 | Jie Zhan | [cpufreq: Support per-policy performance boost](https://lore.kernel.org/all/20230724075827.4160512-1-zhanjie9@hisilicon.com) | 通过添加 "local_boost" sysfs 接口启用按策略提升. 与全局升压开关相同, 将 1/0 写入 "local_boost" 可分别启用 / 禁用 cpufreq 策略上的升压.
全局和本地增压控制的用户视图应为:
1. 启用全局增强最初会对所有策略启用本地增强, 然后可以对每个策略单独启用或禁用本地增强, 前提是平台确实支持.
2. 禁用全局 boost 会使启用本地 boost 成为非法, 而将 0 写入 "local_boost" 是可以的, 但不会生效. [Per-Policy CPU Performance Boosting Proposed For Linux](https://www.phoronix.com/news/Linux-Per-Policy-CPU-Perf-Boost) | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20230724075827.4160512-1-zhanjie9@hisilicon.com) | + ### 7.3.4 各个厂商基于 schedutil 的进一步优化和改进 ------- @@ -5412,6 +5419,8 @@ CONFIG_SCHED_CORE_CTL 的方案, 不光通过 do_isolation_work_cpu_stop() 支 [实时 Linux 内核调度器 | Real-Time Linux Kernel Scheduler](https://rtoax.blog.csdn.net/article/details/113728859) +[A Q&A about the realtime patches](https://lwn.net/Articles/938236) + ## 8.1 抢占支持 (preemption) ------- @@ -5936,16 +5945,21 @@ EEVDF 的核心理念就可以从它的名字中看出, 它将首先运行那些 | cfs_rq | 描述 | 更新时机 | 用途 | 公式 | |:------:|:----:|:-------:|:---:|:---:| -| avg_vruntime | cfs_rq 上所有任务 (调度实体) 的累积带 load.weight 加权的 vruntime 相距 min_vruntime 的偏差和. | 1. 每次进程出入队的时候, 会对 cfs_rq 的 avg_vruntime, avg_slice, avg_load 进行更新. 参见 avg_vruntime_add() 和 avg_vruntime_sub().
2. 由于 avg_vruntime 的计算依赖于 cfs->min_vruntime, 因此每次 update_min_vruntime() 都会通过 avg_vruntime_update(), 对 cfs_rq->avg_vruntime 进行校准. | 1. avg_vruntime() 中使用 cfs_rq->avg_vruntime 来计算归一化的 avg_vruntime.
2. entity_eligible() 中通过判断 cfs_rq->vruntime 或者归一化 avg_runtime 来判断进程是否是 eligible.
3. place_entity() 中使用归一化 avg_vruntime 来更新进程的 vlag 以及 dealine.
4. update_entity_lag() 中使用归一化 avg_vruntime 来更新进程的 vlag. | $$avg\_vruntime_{cfs\_rq} = \sum_{i=0}^{N} (vruntime_{se} - min\_vruntime_{cfs\_rq}) \times load\_weight$$ | -| avg_load | cfs_rq 上所有任务 (调度实体) 的累积 load.weight 和. | 1. 每次进程出入队的时候, 会对 cfs_rq 的 avg_vruntime, avg_slice, avg_load 进行更新. 参见 avg_vruntime_add() 和 avg_vruntime_sub(). | 1. 计算归一化 avg_vruntime 时, 作为分母使用, 做归一.
2. place_entity() 中通过 $$avg\_slice_{cfs\_rq} \gt slice_{se} \times avg\_load_{cfs\_rq}$$ 判断是否要对进程进行补偿.
3. entity_eligible() 中通过 $$avg\_vruntime\_{cfs} \ge entity\_key_{se} = vruntime_{se} - min\_vruntime_{cfs\_rq}$$ 来判断进程是否是 eligible 的. | $$avg\_load_ = \sum_{i=0}^{N} load\_weight$$ | -| avg_slice | cfs_rq 上所有任务 (调度实体) 的累积带 load.weight 加权的 slice 和. 参见 [sched/eevdf: Better handle mixed slice length](https://github.com/gatieme/linux/commit/0b7f7acee08c3b11897c761df9d691a7b47ab4bd) 引入. | 1. 每次进程出入队的时候, 会对 cfs_rq 的 avg_vruntime, avg_slice, avg_load 进行更新. 参见 avg_vruntime_add() 和 avg_vruntime_sub().
| place_entity() 中通过 $$avg\_slice_{cfs\_rq} \gt slice_{se} \times avg\_load_{cfs\_rq}$$ 判断是否要对进程进行补偿. | $$avg\_slice = \sum_{i=0}^{N} slice_{se} \times load\_weight$$ | +| avg_vruntime | cfs_rq 上所有任务 (调度实体) 的累积带 load.weight 加权的 vruntime 相距 min_vruntime 的偏差和. | 1. 每次进程出入队的时候, 会对 cfs_rq 的 avg_vruntime, avg_slice, avg_load 进行更新. 参见 avg_vruntime_add() 和 avg_vruntime_sub().
2. 由于 avg_vruntime 的计算依赖于 cfs->min_vruntime, 因此每次 update_min_vruntime() 都会通过 avg_vruntime_update(), 对 cfs_rq->avg_vruntime 进行校准. | 1. avg_vruntime() 中使用 cfs_rq->avg_vruntime 来计算归一化的 avg_vruntime.
2. entity_eligible() 中通过判断 cfs_rq->vruntime 或者归一化 avg_runtime 来判断进程是否是 eligible.
3. place_entity() 中使用归一化 avg_vruntime 来更新进程的 vlag 以及 dealine.
4. update_entity_lag() 中使用归一化 avg_vruntime 来更新进程的 vlag. | $$avg\_vruntime_{cfs\_rq} = \sum \limits_{i = 0}^{N} (vruntime_{se} - min\_vruntime_{cfs\_rq}) \times load\_weight$$ | +| avg_load | cfs_rq 上所有任务 (调度实体) 的累积 load.weight 和. | 1. 每次进程出入队的时候, 会对 cfs_rq 的 avg_vruntime, avg_slice, avg_load 进行更新. 参见 avg_vruntime_add() 和 avg_vruntime_sub(). | 1. 计算归一化 avg_vruntime 时, 作为分母使用, 做归一.
2. place_entity() 中通过 $$avg\_slice_{cfs\_rq} \gt slice_{se} \times avg\_load_{cfs\_rq}$$ 判断是否要对进程进行补偿.
3. entity_eligible() 中通过 $$avg\_vruntime\_{cfs} \ge entity\_key_{se} = vruntime_{se} - min\_vruntime_{cfs\_rq}$$ 来判断进程是否是 eligible 的. | $$avg\_load_ = \sum \limits_{i = 0}^{N} load\_weight$$ | +| avg_slice | cfs_rq 上所有任务 (调度实体) 的累积带 load.weight 加权的 slice 和. 参见 [sched/eevdf: Better handle mixed slice length](https://github.com/gatieme/linux/commit/0b7f7acee08c3b11897c761df9d691a7b47ab4bd) 引入. | 1. 每次进程出入队的时候, 会对 cfs_rq 的 avg_vruntime, avg_slice, avg_load 进行更新. 参见 avg_vruntime_add() 和 avg_vruntime_sub().
| place_entity() 中通过 $$avg\_slice_{cfs\_rq} \gt slice_{se} \times avg\_load_{cfs\_rq}$$ 判断是否要对进程进行补偿. | $$avg\_slice = \sum \limits_{i = 0}^{N} slice_{se} \times load\_weight$$ | +1. 每次进程出入队的时候, 会对 cfs_rq 的 avg_vruntime, avg_slice, avg_load 进行更新. 参见 avg_vruntime_add() 和 avg_vruntime_sub(). -$$$ -avg\_vruntime_{cfs\_rq}' = avg\_vruntime_{cfs\_rq} - avg\_load_{cfs\_rq} * delta -= \sum_{i=0}^{N} (vruntime_{se} - min\_vruntime_{cfs\_rq}) \times weight - \sum_{i=0}^{N} load\_weight * delta -= \sum_{i=0}^{N} [vruntime_{se} - (min\_vruntime_{cfs\_rq} - delta)] \times weight] -$$$ +$`avg = \frac{avg\_vruntime_{cfs\_rq}}{avg\_load_{cfs\_rq}} = \frac{\sum \limits_{i = 0}^{N} (vruntime_{se} - min\_vruntime_{cfs\_rq}) \times load\_weight}{\sum \limits_{i = 0}^{N} load\_weight}`$ + +2. 由于 avg_vruntime 的计算依赖于 cfs->min_vruntime, 因此每次 update_min_vruntime() 都会通过 avg_vruntime_update(), 对 cfs_rq->avg_vruntime 进行校准. + +$`avg\_vruntime_{cfs\_rq}' = avg\_vruntime_{cfs\_rq} - avg\_load_{cfs\_rq} * delta += \sum \limits_{i = 0}^{N} (vruntime_{se} - min\_vruntime_{cfs\_rq}) \times weight - \sum \limits_{i = 0}^{N} load\_weight * delta += \sum \limits_{i = 0}^{N} [vruntime_{se} - (min\_vruntime_{cfs\_rq} - delta)] \times weight]`$ + +其中 delta 为 min\_vruntime_{cfs\_rq} 的校准值, 即新旧 min\_vruntime_{cfs\_rq} 的差值. * sched_entity 的 vlag 与 deadline @@ -5967,8 +5981,7 @@ $$$ cfs_rq->avg_vruntime 和上缓存了 cfs_rq 上所有任务 (调度实体) 的带 load.weight 加权的 vruntime 累积偏差, cfs_rq->avg_load 则缓存了 cfs_rq 上所有任务 (调度实体) 的累积 load.weight. 两者比值就近似为: cfs_rq 上上所有任务 (调度实体) 的 vruntime (相距离 cfs_rq->min_vruntime) 的带权平均偏差. 再加上 cfs_rq->min_vruntime 就是 cfs_rq 当前的带权归一化的平均 vruntime. 这个值的显示理论含义可以近似为: 就绪队列上所有任务平均获取的 (虚拟) 运行时间. -$$avg = frac{avg\_vruntime_{cfs\_rq}}{avg\_load_{cfs\_rq}} = \frac{\sum_{i=0}^{N} (vruntime_{se} - min\_vruntime_{cfs\_rq}) \times load\_weight}{\sum_{i=0}^{N} load\_weight}$$ -$$avg\_vruntime = min\_vruntime_{cfs\_rq} + avg = min\_vruntime_{cfs\_rq} + frac{avg\_vruntime_{cfs\_rq}}{avg\_load_{cfs\_rq}} = min\_vruntime_{cfs\_rq} + \frac{\sum_{i=0}^{N} (vruntime_{se} - min\_vruntime_{cfs\_rq}) \times load\_weight}{\sum_{i=0}^{N} load\_weight}$$ +$`avg\_vruntime = min\_vruntime_{cfs\_rq} + avg = min\_vruntime_{cfs\_rq} + \frac{avg\_vruntime_{cfs\_rq}}{avg\_load_{cfs\_rq}} = min\_vruntime_{cfs\_rq} + \frac{\sum \limits_{i = 0}^{N} (vruntime_{se} - min\_vruntime_{cfs\_rq}) \times load\_weight}{\sum \limits_{i = 0}^{N} load\_weight}`$ > 此外还有一个细节, 由于 CFS 进程, current(cfs_rq->curr) 每次被 PICK 之后, 会从红黑树出队, 因此 avg_vruntime() 和 entity_eligible() 计算时需要把 cfs_rq->curr 也统计进来. @@ -5977,9 +5990,7 @@ $$avg\_vruntime = min\_vruntime_{cfs\_rq} + avg = min\_vruntime_{cfs\_rq} + frac 有了 cfs_rq 的平均 vruntime, 即就绪队列上所有任务的平均虚拟运行时间, 那么进程实际获得的虚拟运行时间 se->vruntime 相距平均虚拟运行时间 vruntime 的距离, 就是进程 (调度实体) 的 vlag 值. EEVDF 认为 vlag >= 0 的任务是 eligible, vlag < 0 的任务是 !eligible 的. -$$lag = avg\_vruntime_{cfs_rq} - vruntime_{se}$$ - - +$`lag = avg\_vruntime_{cfs_rq} - vruntime_{se}`$ * 如何结合 latency_nice @@ -5991,7 +6002,7 @@ latency_nice 影响的就是 `se->slice` | 2009/09/16 | Ingo Molnar | [sched: Implement a gentler fair-sleepers feature](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51e0304ce6e55a6e59658558916b4f74da085ff0) | 引入 GENTLE_FAIR_SLEEPERS sched_feature 只给睡眠的线程 50% 的 vruntime 补偿优待, 这使它们能够更快地奔跑, 但不会让他们窃取过多的补偿. | v1 ☐☑✓ | [LORE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51e0304ce6e55a6e59658558916b4f74da085ff0) | | 2023/04/01 | Xi Wang | [Morphing CFS into FDL, The Fair Deadline Scheduling Class](https://lore.kernel.org/all/20230401230556.2781604-1-xii@google.com) | TODO | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20230401230556.2781604-1-xii@google.com) | | 2023/03/28 | Peter Zijlstra | [sched: EEVDF using latency-nice](https://lore.kernel.org/all/20230328092622.062917921@infradead.org) | [EEVDF Scheduler Patches Updated For The Linux Kernel](https://www.phoronix.com/news/Linux-EEVDF-EO-March) | v1 ☐☑✓ | [LORE 00/10](https://lore.kernel.org/all/20230306132521.968182689@infradead.org)
*-*-*-*-*-*-*-*
[LORE v1,0/17](https://lore.kernel.org/all/20230328092622.062917921@infradead.org) | -| 2023/05/31 | Peter Zijlstra | [sched: EEVDF and latency-nice and/or slice-attr](https://lore.kernel.org/all/20230531115839.089944915@infradead.org) | [Updated EEVDF Linux CPU Scheduler Patches Posted That Plan To Replace CFS](https://www.phoronix.com/news/EEVDF-Scheduler-Linux-EO-May) 以及 [EEVDF Scheduler May Be Ready For Landing With Linux 6.6](https://www.phoronix.com/news/Linux-6.6-EEVDF-Likely). | v1 ☐☑✓ | [LORE v1,0/15](https://lore.kernel.org/all/20230531115839.089944915@infradead.org) | +| 2023/07/19 | Peter Zijlstra | [sched: EEVDF and latency-nice and/or slice-attr](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=b41bbb33cf75d251a816768580819aec17be718d) | [Updated EEVDF Linux CPU Scheduler Patches Posted That Plan To Replace CFS](https://www.phoronix.com/news/EEVDF-Scheduler-Linux-EO-May) 以及 [EEVDF Scheduler May Be Ready For Landing With Linux 6.6](https://www.phoronix.com/news/Linux-6.6-EEVDF-Likely). | v1 ☐☑✓ 6.6-rc1 | [LORE v1,0/15](https://lore.kernel.org/all/20230531115839.089944915@infradead.org), [CGIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=d07f09a1f99cabbc86bc5c97d962eb8a466106b5) | ### 8.9.2 Xen CPU Scheduling @@ -6399,7 +6410,7 @@ Roman Gushchin 在邮件列表发起了 BPF 对调度器的潜在应用的讨论 | 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 | |:----:|:----:|:---:|:----:|:---------:|:----:| | 2021/09/15 | Roman Gushchin | [Scheduler BPF](https://www.phoronix.com/scan.php?page=news_item&px=Linux-BPF-Scheduler) | NA | RFC ☐ | [PatchWork rfc,0/6](https://patchwork.kernel.org/project/netdevbpf/cover/20210916162451.709260-1-guro@fb.com)
*-*-*-*-*-*-*-*
[LPC 2021](https://linuxplumbersconf.org/event/11/contributions/954)
*-*-*-*-*-*-*-*
[LKML](https://lkml.org/lkml/2021/9/16/1049), [LWN](https://lwn.net/Articles/869433), [LWN](https://lwn.net/Articles/873244) | -| 2022/11/29 | Tejun Heo | [sched: Implement BPF extensible scheduler class](https://lore.kernel.org/all/20221130082313.3241517-1-tj@kernel.org) | 随后 FaceBook 进一步扩展, 引入 sched_ext 模块, 使用 eBPF 对调度器进行可编程重构. [Experimental Patches Allow eBPF To Extend The Linux Kernel's Scheduler](https://www.phoronix.com/news/RFC-eBPF-Linux-Scheduler), [The BPF extensible scheduler class](https://lwn.net/Articles/916291), [The extensible scheduler class](https://lwn.net/Articles/922405/), [Patches Updated For Hooking eBPF Programs Into The Linux Kernel Scheduler](https://www.phoronix.com/news/Linux-Scheduler-eBPF-v2-sched). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221130082313.3241517-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[LORE v2,00/30](https://lore.kernel.org/lkml/20230128001639.3510083-1-tj@kernel.org) | +| 2022/11/29 | Tejun Heo | [sched: Implement BPF extensible scheduler class](https://lore.kernel.org/all/20221130082313.3241517-1-tj@kernel.org) | 随后 FaceBook 进一步扩展, 引入 sched_ext 模块, 使用 eBPF 对调度器进行可编程重构. [Experimental Patches Allow eBPF To Extend The Linux Kernel's Scheduler](https://www.phoronix.com/news/RFC-eBPF-Linux-Scheduler), [The BPF extensible scheduler class](https://lwn.net/Articles/916291), [The extensible scheduler class](https://lwn.net/Articles/922405/), [Patches Updated For Hooking eBPF Programs Into The Linux Kernel Scheduler](https://www.phoronix.com/news/Linux-Scheduler-eBPF-v2-sched). 以及 [Extensible scheduler class rejected](https://lwn.net/Articles/939332) | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20221130082313.3241517-1-tj@kernel.org)
*-*-*-*-*-*-*-*
[LORE v2,00/30](https://lore.kernel.org/lkml/20230128001639.3510083-1-tj@kernel.org) | #### 11.2.2.2 Google 的 ghOSt @@ -6687,7 +6698,7 @@ ECRTS 2020(32nd Euromicro Conference on Real-Time Systems) 上 Daniel 等人发 | 1 | SchedViz | [Understanding Scheduling Behavior with SchedViz](https://opensource.googleblog.com/2019/10/understanding-scheduling-behavior-with.html) | [google/schedviz, github](https://github.com/google/schedviz) | | 2 | systrace | NA | NA | | 3 | perfetto | NA | NA | - +| 4 | Sysprof | [GNOME's Sysprof Integrates CPU Scheduler Data](https://www.phoronix.com/news/Sysprof-Adds-CPU-Scheduler-Data), [add support for tracking scheduler details](https://gitlab.gnome.org/GNOME/sysprof/-/merge_requests/74) | ** 引用: ** diff --git a/study/kernel/00-DESCRIPTION/TODO.md b/study/kernel/00-DESCRIPTION/TODO.md index 234ca55..b5c7773 100644 --- a/study/kernel/00-DESCRIPTION/TODO.md +++ b/study/kernel/00-DESCRIPTION/TODO.md @@ -161,7 +161,6 @@ khugepage_code 将选择命中率最高的节点作为首选节点, 并尝试在 | 2022/04/06 | Liao Chang | [softirq: Introduce softirq throttling](https://lore.kernel.org/all/20220406022749.184807-1-liaochang1@huawei.com) | TODO | v1 ☐☑✓ | [LORE v1,0/3](https://lore.kernel.org/all/20220406022749.184807-1-liaochang1@huawei.com) | -| 2023/03/29 | Yicong Yang | [arm64: support batched/deferred tlb shootdown during page reclamation](https://patchwork.kernel.org/project/linux-mm/cover/20230329035512.57392-1-yangyicong@huawei.com/) | 734835 | v8 ☐☑ | [LORE v8,0/2](https://lore.kernel.org/r/20230329035512.57392-1-yangyicong@huawei.com) | | 2023/03/29 | Luis Chamberlain | [module: avoid userspace pressure on unwanted allocations](https://patchwork.kernel.org/project/linux-mm/cover/20230329053149.3976378-1-mcgrof@kernel.org/) | 734852 | v1 ☐☑ | [LORE v1,0/7](https://lore.kernel.org/r/20230329053149.3976378-1-mcgrof@kernel.org) | | 2023/03/30 | Longlong Xia | [mm: ksm: support hwpoison for ksm page](https://patchwork.kernel.org/project/linux-mm/cover/20230330074501.205092-1-xialonglong1@huawei.com/) | 735257 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20230330074501.205092-1-xialonglong1@huawei.com) | | 2023/03/30 | Yosry Ahmed | [memcg: avoid flushing stats atomically where possible](https://patchwork.kernel.org/project/linux-mm/cover/20230330191801.1967435-1-yosryahmed@google.com/) | 735542 | v3 ☐☑ | [LORE v3,0/8](https://lore.kernel.org/r/20230330191801.1967435-1-yosryahmed@google.com) | @@ -504,9 +503,7 @@ BPF verifiery 已经做了很多工作来尽量确保加载进 kernel 的 BPF pr | 2023/06/21 | Matthew Wilcox | [Remove pagevecs](https://patchwork.kernel.org/project/linux-mm/cover/20230621164557.3510324-1-willy@infradead.org/) | 759217 | v1 ☐☑ | [LORE v1,0/13](https://lore.kernel.org/r/20230621164557.3510324-1-willy@infradead.org) | | 2023/06/21 | Yuanchu Xie | [mm: working set reporting](https://patchwork.kernel.org/project/linux-mm/cover/20230621180454.973862-1-yuanchu@google.com/) | 759245 | v2 ☐☑ | | | 2023/06/22 | Kasireddy, Vivek | [udmabuf: Add back support for mapping hugetlb pages](https://patchwork.kernel.org/project/linux-mm/cover/20230622072710.3707315-1-vivek.kasireddy@intel.com/) | 759373 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20230622072710.3707315-1-vivek.kasireddy@intel.com) | -| 2023/06/22 | Qi Zheng | [use refcount+RCU method to implement lockless slab shrink](https://patchwork.kernel.org/project/linux-mm/cover/20230622085335.77010-1-zhengqi.arch@bytedance.com/) | 759412 | v1 ☐☑ | [LORE v1,0/29](https://lore.kernel.org/r/20230622085335.77010-1-zhengqi.arch@bytedance.com) | | 2023/06/22 | Ryan Roberts | [Transparent Contiguous PTEs for User Mappings](https://patchwork.kernel.org/project/linux-mm/cover/20230622144210.2623299-1-ryan.roberts@arm.com/) | 759528 | v1 ☐☑ | [LORE v1,0/14](https://lore.kernel.org/r/20230622144210.2623299-1-ryan.roberts@arm.com) | -| 2023/06/26 | Ryan Roberts | [variable-order, large folios for anonymous memory](https://patchwork.kernel.org/project/linux-mm/cover/20230626171430.3167004-1-ryan.roberts@arm.com/) | 760361 | v1 ☐☑ | [LORE v1,0/10](https://lore.kernel.org/r/20230626171430.3167004-1-ryan.roberts@arm.com)
*-*-*-*-*-*-*-*
[LORE v4,0/5](https://lore.kernel.org/r/20230726095146.2826796-1-ryan.roberts@arm.com) | | 2023/06/27 | zhaoyang.huang | [mm: introduce statistic for inode's gen&tier](https://patchwork.kernel.org/project/linux-mm/patch/1687857438-29142-1-git-send-email-zhaoyang.huang@unisoc.com/) | 760556 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/1687857438-29142-1-git-send-email-zhaoyang.huang@unisoc.com) | | 2023/06/27 | Chuck Lever | [shmemfs stable directory offsets](https://patchwork.kernel.org/project/linux-mm/cover/168789864000.157531.11122232592994999253.stgit@manet.1015granger.net/) | 760743 | v5 ☐☑ | [LORE v5,0/3](https://lore.kernel.org/r/168789864000.157531.11122232592994999253.stgit@manet.1015granger.net) | | 2023/07/10 | Yajun Deng | [dma-contiguous: support numa CMA for specified node](https://patchwork.kernel.org/project/liux-mm/patch/20230710074944.3501810-1-yajun.deng@linux.dev/) | 763917 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230710074944.3501810-1-ajun.deng@linux.dev)
*-*-*-*-*-*-*-*
[LORE v2,0/1](https://lore.kernel.org/r/20230711110822.1105785-1-yajun.deng@linux.dev) | @@ -515,8 +512,8 @@ BPF verifiery 已经做了很多工作来尽量确保加载进 kernel 的 BPF pr | 2023/07/23 | Hyeonggon Yoo <42.hyeyoo@gmail.com> | [An attempt to improve SLUB on NUMA / under memory pressure](https://patchwork.kernel.org/project/linux-mm/cover/20230723190906.4082646-1-42.hyeyoo@gmail.com/) | 768670 | v1 ☐☑ | [LORE v1,0/2](https://lore.kernel.org/r/20230723190906.4082646-1-42.hyeyoo@gmail.com) | | 2023/07/23 | Hugh Dickins | [[v3,11/13,fix] mm/khugepaged: delete khugepaged_collapse_pte_mapped_thps(): fix](https://patchwork.kernel.org/project/linux-mm/patch/bfc6cab2-497f-32bf-dd5-98dc1987e4a9@google.com/) | 768689 | v3 ☐☑ | [LORE v3,0/13](https://lore.kernel.org/r/bfc6cab2-497f-32bf-dd5-98dc1987e4a9@google.com) | | 2023/07/24 | Zhongkun He | [zram: memcg accounting](https://patchwork.kernel.org/project/linux-mm/cover/20230724062143.2244078-1-hezhongkun.hzk@bytedance.com/) | 768727 | v2 ☐☑ | [LORE v2,0/2](https://lore.kernel.org/r/20230724062143.2244078-1-hezhongkun.hzk@bytedance.com) | -| 2023/07/24 | Mark Brown | [arm64/gcs: Provide support for GCS in userspace](https://patchwork.kernel.org/project/linux-mm/cover/20230724-arm64-gcs-v2-0-dc2c1d44c2eb@kernel.org/) | 768889 | v2 ☐☑ | [LORE v2,0/35](https://lore.kernel.org/r/20230724-arm64-gcs-v2-0-dc2c1d44c2eb@kernel.org) | -| 2023/07/24 | Qi Zheng | [use refcount+RCU method to implement lockless slab shrink](https://patchwork.kernel.org/project/linux-mm/cover/20230724094354.90817-1-zhengqi.arch@bytedance.com/) | 768800 | v2 ☐☑ | [LORE v2,0/47](https://lore.kernel.org/r/20230724094354.90817-1-zhengqi.arch@bytedance.com)
*-*-*-*-*-*-*-*
[LORE v3,0/49](https://lore.kernel.org/r/20230727080502.77895-1-zhengqi.arch@bytedance.com) | + + | 2023/07/27 | Ryan Roberts | [Optimize large folio interaction with deferred split](https://patchwork.kernel.org/project/linux-mm/cover/20230727141837.3386072-1-ryan.roberts@arm.com/) | 770154 | v4 ☐☑ | [LORE v4,0/3](https://lore.kernel.org/r/20230727141837.3386072-1-ryan.roberts@arm.com) | @@ -524,7 +521,54 @@ BPF verifiery 已经做了很多工作来尽量确保加载进 kernel 的 BPF pr +[Much ado about SBAT](https://lwn.net/Articles/938422) + +[Challenges for KernelCI](https://lwn.net/Articles/939538) + + + + + +[An ioctl() call to detect memory writes](https://lwn.net/Articles/940704) +[BPF iterators for filesystems](https://lwn.net/Articles/937326) +[Exceptions in BPF](https://lwn.net/Articles/938435) +[Randomness for kmalloc()](https://lwn.net/Articles/938637) +[Beginning the software-interrupt lock pushdown](https://lwn.net/Articles/939973) +[Following up on file-position locking](https://lwn.net/Articles/940808) +[Out-of-memory victim selection with BPF](https://lwn.net/Articles/941614) + + + + +[一文读懂｜Linux 进程管理之 CFS 负载均衡](https://www.qinglite.cn/doc/4126647762640fe5c) +[CFS 任务的负载均衡 (load balance)](http://www.wowotech.net/process_management/load_balance_detail.html) +[步道师 Peter-CFS 任务的负载均衡](https://blog.csdn.net/melody157398/article/details/106449788) +[步道师 Peter-CFS 任务的负载均衡 (框架篇)](https://blog.csdn.net/melody157398/article/details/105445504/) +[内核工匠 - CFS 任务的负载均衡](https://blog.csdn.net/feelabclihu/article/details/106435849) + + +| 2023/07/28 | Fabio M. De Francesco | [Documentation/page_tables: Add info about MMU/TLB and Page Faults](https://patchwork.kernel.org/project/linux-mm/patch/20230728120054.12306-1-fmdefrancesco@gmail.com/) | 770552 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230728120054.12306-1-fmdefrancesco@gmail.com) | +| 2023/08/04 | Zhongkun He | [zram: memcg accounting](https://patchwork.kernel.org/project/linux-mm/cover/20230804075720.207943-1-hezhongkun.hzk@bytedance.com/) | 772958 | v2 ☐☑ | [LORE v2,0/2](https://lore.kernel.org/r/20230804075720.207943-1-hezhongkun.hzk@bytedance.com) | +| 2023/08/04 | Liam Ni | [NUMA:Improve the efficiency of calculating pages loss](https://patchwork.kernel.org/project/linux-mm/patch/CACZJ9cUXiWxDb6hF4JFhWe7Np82k6LopVQ+_AoGFOccN4kjJqA@mail.gmail.com) | 773185 | v3 ☐☑ | [LORE v3,0/1](https://lore.kernel.org/r/CACZJ9cUXiWxDb6hF4JFhWe7Np82k6LopVQ+_AoGFOccN4kjJqA@mail.gmail.com) | +| 2023/08/08 | Yan Zhao | [Reduce NUMA balance caused TLB-shootdowns in a VM](https://patchwork.kernel.org/project/linux-mm/cover/20230808071329.19995-1-yan.y.zhao@intel.com/) | 773948 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20230808071329.19995-1-yan.y.zhao@intel.com)
*-*-*-*-*-*-*-*
[LORE v2,0/5](https://lore.kernel.org/r/20230810085636.25914-1-yan.y.zhao@intel.com) | +| 2023/08/08 | Jinliang Zheng | [writeback: remove redundant checks for root memcg](https://patchwork.kernel.org/project/linux-mm/patch/20230808084431.1632934-1-alexjlzheng@tencent.com/) | 773962 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20230808084431.1632934-1-alexjlzheng@tencent.com) | +| 2023/08/17 | Kasireddy, Vivek | [udmabuf: Add back support for mapping hugetlb pages (v3)](https://patchwork.kernel.org/project/linux-mm/cover/20230817064623.3424348-1-vivek.kasireddy@intel.com/) | 776879 | v3 ☐☑ | [LORE v3,0/2](https://lore.kernel.org/r/20230817064623.3424348-1-vivek.kasireddy@intel.com) | +| 2023/08/17 | Kasireddy, Vivek | [udmabuf: Add support for page migration out of movable zone or CMA](https://patchwork.kernel.org/project/linux-mm/cover/20230817064934.3424431-1-vivek.kasireddy@intel.com/) | 776880 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/20230817064934.3424431-1-vivek.kasireddy@intel.com) | + + + + + +$$$ +avg\_vruntime_{cfs\_rq}' = avg\_vruntime_{cfs\_rq} - avg\_load_{cfs\_rq} * delta += \sum_{i=0}^{N} (vruntime_{se} - min\_vruntime_{cfs\_rq}) \times weight - \sum_{i=0}^{N} load\_weight * delta += \sum_{i=0}^{N} [vruntime_{se} - (min\_vruntime_{cfs\_rq} - delta)] \times weight] +$$$ + + +$`avg\_vruntime_{cfs\_rq}' = avg\_vruntime_{cfs\_rq} - avg\_load_{cfs\_rq} * delta += \sum \limits_{i = 0}^{N} (vruntime_{se} - min\_vruntime_{cfs\_rq}) \times weight - \sum \limits_{i = 0}^{N} load\_weight * delta += \sum \limits_{i = 0}^{N} [vruntime_{se} - (min\_vruntime_{cfs\_rq} - delta)] \times weight]`$ -这是新空闲平衡优化 [Limit the scan depth to find the busiest sched group during newidle balance](https://lore.kernel.org/all/cover.1686554037.git.yu.c.chen@intel.com) 的新版本. 它旨在降低新空闲平衡的成本, 在一些高核计数系统上, 新空闲平衡被发现占用了明显的 CPU 周期. 例如, 当在 Intel Sapphire Rapids 上运行 sqlite 时, 它有 2 x 56C/112T = 224 个 cpu: newidle_balance 以及 update_sd_lb_stats 的热点达到 5% 以上. 为了减少这一开销, Tim 提出的问题启发了我们进行优化:
1. 第一个是 ILB_UTIL. 建议在 update_sd_lb_stats() 中限制扫描深度. 扫描深度取决于该调度域的总体利用率. 利用率越高, update_sd_lb_stats() 扫描的数据就越少. 亦然.
2. 第二个是 ILB_FAST. 与其总是在 update_sd_lb_stats() 中查找最繁忙的组, 不如降低标准并尝试查找相对繁忙的组. 当本地组为 group_has_spare 时, ILB_FAST 生效. 因为当有许多 cpu 并发地运行 newidle_balance() 时, 计划组应该有很高的空闲百分比.
3. 与 ILB_UTIL 和 ILB_FAST 相比, ILB_UTIL 抑制了系统繁忙时的调度组扫描. 后者在系统不忙时选择折衷的忙群. 它们相互补充, 独立工作. diff --git a/study/kernel/00-DESCRIPTION/TOOLS.md b/study/kernel/00-DESCRIPTION/TOOLS.md index d1da0a4..666c68f 100644 --- a/study/kernel/00-DESCRIPTION/TOOLS.md +++ b/study/kernel/00-DESCRIPTION/TOOLS.md @@ -116,7 +116,7 @@ Intel 发布的 ControlFlag 用机器学习来发现代码中的错误, 支持 C |:----:|:----:|:---:|:----:|:---------:|:----:| | 2019/06/23 | 胡俊鹏 and | [dongzhiyan-stack/user_stack_backstrace-in-kernel](https://github.com/dongzhiyan-stack/user_stack_backstrace-in-kernel) | 海康 CLK 2019 的一个 slides, 内核态回溯用户态栈. 对于一些比较难解析符号的场景也有对策 | v1 ☐ | [github](https://github.com/dongzhiyan-stack/user_stack_backstrace-in-kernel) | | 2012/4/11 | "Tu, Xiaobing" | [kernel patch for dump user space stack tool](https://lkml.org/lkml/2012/4/11/49) | 内核态回溯用户态栈. | v1 ☐ | [LKML RFC 1/2](https://lkml.org/lkml/2012/4/11/49) | -| 2023/05/01 | Indu Bhagat | [SFrame based stack tracer for user space in the kernel](https://lore.kernel.org/all/20230501200410.3973453-1-indu.bhagat@oracle.com) | [Reliable user-space stack traces with SFrame](https://lwn.net/Articles/932209) | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20230501200410.3973453-1-indu.bhagat@oracle.com) | +| 2023/05/01 | Indu Bhagat | [SFrame based stack tracer for user space in the kernel](https://lore.kernel.org/all/20230501200410.3973453-1-indu.bhagat@oracle.com) | [Reliable user-space stack traces with SFrame](https://lwn.net/Articles/932209) 以及 [SFrame: fast, low-overhead stack traces](https://lwn.net/Articles/940686). | v1 ☐☑✓ | [LORE v1,0/5](https://lore.kernel.org/all/20230501200410.3973453-1-indu.bhagat@oracle.com) | ## 2.4 patchwork