Mirrors_BOOKS/LDD-LinuxDeviceDrivers
1
0 Fork 0
mirror of https://github.com/gatieme/LDD-LinuxDeviceDrivers.git synced 2026-11-09 08:38:04 +08:00
Code Issues Packages Projects Releases Wiki Activity

description/memory: page cache

Browse Source
This commit is contained in:
Cheng Jian committed 2022-03-05 22:51:54 +08:00
1 parent f07768fe3c
commit 334e3fb553
5 files changed
+52 -5
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

study/kernel/00-DESCRIPTION/ARCH.md
+1 -1
View File
@@ -325,7 +325,7 @@ TLB entry shootdown 常常或多或少的带来一些性能问题.
| 2020/11/03 | Nianyao Tang <tangnianyao@huawei.com> | [KVM: arm64: Don't force broadcast tlbi when guest is running](https://lists.cs.columbia.edu/pipermail/kvmarm/2020-November/043071.html) | KVM 当 guest 在运行的时候, 避免 tlbi 广播. | RFC v1 ☐ | [Patchwork RTC](https://lore.kernel.org/linux-arm-kernel/1603331829-33879-1-git-send-email-zhangshaokun@hisilicon.com) |
| 2019/06/17 | Takao Indoh <indou.takao@jp.fujitsu.com> | [arm64: Introduce boot parameter to disable TLB flush instruction within the same inner shareable domain](hhttps://lists.cs.columbia.edu/pipermail/kvmarm/2020-November/043071.html) | 富士通的开发人员发现 ARM64 TLB.IS 广播在 HPC 上造成了严重的性能下降, 因此新增一个 disable_tlbflush_is 参数来禁用 TLB.IS 广播, 使用原始的 TLB IPI 方式. | RFC v1 ☐ | [Patchwork 0/2](https://patchwork.kernel.org/project/linux-arm-kernel/cover/20190617143255.10462-1-indou.takao@jp.fujitsu.com), [LORE](https://lore.kernel.org/linux-arm-kernel/20190617143255.10462-1-indou.takao@jp.fujitsu.com) |
| 2016/10/24 | Marc Zyngier <marc.zyngier@arm.com> | [arm/arm64: KVM: Perform local TLB invalidation when multiplexing vcpus on a single CPU](https://patchwork.kernel.org/project/kvm/patch/1477323088-18768-1-git-send-email-marc.zyngier@arm.com) | KVM 当 guest 在运行的时候, 避免 tlbi 广播. | RFC v1 ☐ | [Patchwork RTC](https://lore.kernel.org/linux-arm-kernel/1603331829-33879-1-git-send-email-zhangshaokun@hisilicon.com) |
| 2020/02/23 | Andrea Arcangeli <aarcange@redhat.com> | [arm64: tlb: skip tlbi broadcast v2](https://lore.kernel.org/all/20200223192520.20808-1-aarcange@redhat.com) |20200223192520.20808-1-aarcange@redhat.com | v1 ☐ | [LORE](https://lore.kernel.org/all/20200223192520.20808-1-aarcange@redhat.com) |
> 注: x86 由于没有 tlb IS 方案, 因此只能采用 IPI 的方式来完成 TLB shootdown.
study/kernel/00-DESCRIPTION/DEBUGGING.md
+10
View File
@@ -530,6 +530,16 @@ https://patchwork.kernel.org/project/linux-trace-devel/list/?submitter=200911&st
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2021/11/09 | Sai Prakash Ranjan <quic_saipraka@quicinc.com> | [tracing/rwmmio/arm64: Add support to trace register reads/writes](https://patchwork.kernel.org/project/linux-arm-kernel/cover/cover.1636452784.git.quic_saipraka@quicinc.com) | MMIO register read/write tracing. | v3 ☐ | [Patchwork v3,0/3](https://patchwork.kernel.org/project/linux-arm-kernel/cover/cover.1636452784.git.quic_saipraka@quicinc.com) |
## 14.7 ftrace_direct
-------
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2019/11/8 | Steven Rostedt | [ftrace: Add register_ftrace_direct()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=a3ad1a7e39689005cb04a4f2adb82f9d55b4724f) | 1615872606-56087-1-git-send-email-aubrey.li@intel.com | v1 ☑✓ 5.5-rc1 | [LORE 00/10](https://lkml.org/lkml/headers/2019/11/8/1675) |
| 2019/08/27 | Peter Zijlstra <peterz@infradead.org> | [Rewrite x86/ftrace to use text_poke()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=768ae4406a5cab7e8702550f2446dbeb377b798d) | 615872606-56087-1-git-send-email-aubrey.li@intel.com | v3 ☑✓ 5.6-rc1 | [LORE v3,0/3](https://lore.kernel.org/all/20190827180622.159326993@infradead.org) |
| 2021/06/05 | Jiri Olsa <jolsa@kernel.org> | [x86/ftrace/bpf: Add batch support for direct/tracing attach](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=a3ad1a7e39689005cb04a4f2adb82f9d55b4724f) | 1615872606-56087-1-git-send-email-aubrey.li@intel.com | RRC,v3 ☐ | [LORE RRC,v3,00/19](https://lkml.kernel.org/netdev/20210605111034.1810858-1-jolsa@kernel.org) |
| 2021/10/8 | Jiri Olsa <jolsa@kernel.org> | [x86/ftrace: Add direct batch interface](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=5fae941b9a6f95773df644e7cf304bf199707876) | 1615872606-56087-1-git-send-email-aubrey.li@intel.com | v2 ☑✓ 5.16-rc1 | [LKML v2,0/8](https://lkml.org/lkml/2021/10/8/186), [LORE v2,0/8](https://lore.kernel.org/all/20211008091336.33616-1-jolsa@kernel.org) |
# 15 kptr_restrict
-------
study/kernel/00-DESCRIPTION/LIVE_PATCH.md
+1
View File
@@ -23,6 +23,7 @@ https://www.infoworld.com/article/2851028/four-ways-linux-is-headed-for-no-downt
第 1 节内容参照 [History of Linux Kernel Live Patching](https://www.howtoforge.com/history-of-linux-kernel-live-patching)
Google 设计了一套新的用户空间实时补丁创建工具, [LLpatch](https://github.com/google/LLpatch), 基于 llvm-diff 生成 LLVM-IR 完成 ELF 分析和操作, 因此不需要感知特性架构的二进制差异行为. 参见 [announcing LLpatch: arch-independent live-patch creation](https://lore.kernel.org/live-patching/CABFpvm2o+d0e-dfmCx7H6=8i3QQS_xyGFt4i3zn8G=Myr_miag@mail.gmail.com).
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
study/kernel/00-DESCRIPTION/MEMORY_MANAGER.md
+32 -4
View File
@@ -741,6 +741,7 @@ Mel Gorman 发现了这一问题, 开发了 [Calculate pcp->high based on zone s
| 2021/09/21 | Sebastian Andrzej Siewior <bigeasy@linutronix.de> | [mm/swap: Add static key dependent pagevec locking](https://patchwork.kernel.org/project/linux-mm/cover/20190424111208.24459-1-bigeasy@linutronix.de) | 本系列实现了swap 的代码路径中通过禁用抢占来同步它对 per-cpu pagevec 结构体的访问. 这是可行的, 需要从中断上下文访问的结构体是通过禁用中断来保护的.<br>有一种情况下, 需要访问远程 CPU 的 per-cpu 数据, 在 v1 版本中, 试图添加每个 cpu 的自旋锁来访问结构体. 这将增加 lockdep 覆盖率和从远程 CPU 的访问, 不需要 worker.<br>在 v2 中这是通过在远程 CPU 上启动一个 worker 并等待它完成来解决的.<br>关于无争用 spin_lock () 的代价, 以及避免每个 cpu worker 的好处很少, 因为它很少被使用. 然后听从社区的建议使用 static key use_pvec_lock, 在某些情况下(如 NOHZ_FULL 情况), 它支持每个 cpu 的锁定. | v1 ☐ | [PatchWork 0/4,v2](https://patchwork.kernel.org/project/linux-mm/cover/20190424111208.24459-1-bigeasy@linutronix.de) |
| 2021/09/21 | Nicolas Saenz Julienne <nsaenzju@redhat.com> | [mm: Remote LRU per-cpu pagevec cache/per-cpu page list drain support](https://patchwork.kernel.org/project/linux-mm/cover/20210921161323.607817-1-nsaenzju@redhat.com) | 本系列介绍了 mm/swap.c 的每个 CPU LRU pagevec 缓存和 mm/page_alloc 的每个 CPU 页面列表的另一种锁定方案 remote_pcpu_cache_access, 这将允许远程 CPU 消耗它们.<br>目前, 只有一个本地 CPU 被允许更改其每个 CPU 列表, 并且当进程需要它时, 它会按需这样做 (通过在本地 CPU 上排队引流任务).<br>大多数系统会迅速处理这个问题, 但它会给 NOHZ_FULL CPU 带来问题, 这些 CPU 无法在不破坏其功能保证(延迟、带宽等) 的情况下接受任何类型的中断. 如果这些进程能够远程耗尽列表本身, 就可以与隔离的 CPU 共存, 但代价是更多的锁约束.<br>通过 static key remote_pcpu_cache_access 来控制该特性的开启与否, 对于非 nohz_full 用户来说, 默认禁用它, 这保证了最小的功能或性能退化. 而只有当 NOHZ_FULL 的初始化过程成功时, 该特性才会被启用. | v2 ☐ | [2021/09/21 PatchWork 0/6](https://patchwork.kernel.org/project/linux-mm/cover/20210921161323.607817-1-nsaenzju@redhat.com)<br>*-*-*-*-*-*-*-* <br>[2021/11/03 PatchWork v2,0/3](https://patchwork.kernel.org/project/linux-mm/cover/20211103170512.2745765-1-nsaenzju@redhat.com) |
| 2022/02/08 | Nicolas Saenz Julienne <nsaenzju@redhat.com> | [mm/page_alloc: Remote per-cpu lists drain support](https://lore.kernel.org/all/20220208100750.1189808-1-nsaenzju@redhat.com) | 参见 [Remote per-CPU page list draining](https://lwn.net/Articles/884448) | v1 ☐☑✓ | [LORE v1,0/2](https://lore.kernel.org/all/20220208100750.1189808-1-nsaenzju@redhat.com) |
| 2022/02/24 | Suren Baghdasaryan <surenb@google.com> | [mm: page_alloc: replace mm_percpu_wq with kthreads in drain_all_pages](https://lore.kernel.org/all/20220225012819.1807147-1-surenb@google.com) | 20220225012819.1807147-1-surenb@google.com | v1 ☐☑✓ | [LORE v1,0/1](https://lore.kernel.org/all/20220225012819.1807147-1-surenb@google.com) |
### 2.2.6 ALLOC_NOFRAGMENT 优化
@@ -2162,20 +2163,21 @@ swappiness 参数值可设置范围在 `0~100` 之间.
# 6 PageCache
-------
[The future of the page cache](https://lwn.net/Articles/712467)
[vmtouch](https://github.com/hoytech/vmtouch) 是一个 Linux 下管理和控制文件系统缓存的工具. 它可以用来, 查看一个文件(或者目录)哪些部分在内存中, 把文件调入内存, 把文件清除出内存, 把文件锁住在内存中而不被换出到磁盘上. 参见 [vmtouch——Linux 下的文件缓存管理神器播](https://blog.csdn.net/weixin_29762151/article/details/116554695), [vmtouch - the Virtual Memory Toucher](https://www.cnblogs.com/zengkefu/p/5636273.html), [vmtouch 实现原理解析](https://blog.csdn.net/DKH63671763/article/details/87990669), [ebpf 实践之 查看文件占用的缓存大小](https://www.jianshu.com/p/32aff371d6f5)
## 6.1 PAGE CACHE
-------
| 补丁 | 描述 |
|:---:|:---:|
| [Import 1.1.69](https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/diff/mm/filemap.c?id=ea8a68b948397fa9cd1c8a1a6b61a4dc4bc99ec5) | 引入 page cache |
| [Import 1.3.21](https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/diff/mm/filemap.c?id=13e539119b02e4af5daf6c55b31e6273c9a084a6) | 完善了 page cache 的功能 |
| [Import 1.3.50](https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/diff/mm/filemap.c?id=22accfc2b4fe4bc6a635c70c1a05a9a80abc81ea) | 引入了 shrink_mmap() 机制来释放 page cache 的空间. |
| [Import 1.3.53](https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/diff/mm/filemap.c?id=0e8625c7689bef9a38293aa927add4d9704e48be) | 引入了 page_cache_size, 统计 page cache 的大小. |
| [Linux 2.3.7pre1](https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/diff/mm/filemap.c?h=2.3.7pre1&id=344971f8de0ecf3fb7ea642e319aad5865b23529) |
统一了 page cache 和 buffer 的框架. |
| [Linux 2.3.7pre1](https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/diff/mm/filemap.c?h=2.3.7pre1&id=344971f8de0ecf3fb7ea642e319aad5865b23529) | 统一了 page cache 和 buffer 的框架. |
| [Import 2.3.16pre1](https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/diff/mm/filemap.c?id=9aa2c66ac214f71cb051ba7c1adf313d9e160ee1) | 引入了 pagemap-LRU |
@@ -2287,6 +2289,23 @@ Linux内核的一大特色就是支持最多的文件系统, 并拥有一个虚
| 2011/05/17 | WU Fengguang <wfg@mail.ustc.edu.cn> | [on-demand readahead](https://lwn.net/Articles/235164) | on-demand 预读算法 | v1 ☑ [2.6.23-rc1](https://kernelnewbies.org/Linux_2_6_23#On-demand_read-ahead) | [LWN](https://lwn.net/Articles/234784) |
### 6.2.4 Page Cache Fault
-------
```cpp
do_read_fault()
-=> do_fault_around()
```
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:-----:|:----:|:----:|:----:|:------------:|:----:|
| 2014/04/07 | Kirill A. Shutemov <kirill.shutemov@linux.intel.com> | [mm: map few pages around fault address ifthey are in page cache](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=f1820361f83d556a7f0a9f629100f3825e594328) | 文件页读取触发 page_fault 时, do_read_fault() 处理过程中, 如果发现当前文件页有 page cache 映射, 则尝试围绕缺页异常的地址预读更多的文件页面, 减少缺页异常次数. 使用 [vm_ops->map_pages()](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8c6e50b0290c4c708a3e6462729e1e9151a9a7df)(默认是 filemap_map_pages()) 来完成预读. | v3 ☑✓ 3.15-rc1 | [LORE v3,0/2](https://lore.kernel.org/all/1393530827-25450-1-git-send-email-kirill.shutemov@linux.intel.com) |
| 2014/06/04 | "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> | [mm: document do_fault_around() feature](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=1fdb412bd825998efbced3a16f6ce7e0329728cf) | TODO | v1 ☑✓ 3.16-rc1 | [LORE](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=1fdb412bd825998efbced3a16f6ce7e0329728cf) |
| 2014/07/23 | Konstantin Khlebnikov <koct9i@gmail.com> | [mm: do not call do_fault_around for non-linear fault](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c118678bc79e8241f9d3434d9324c6400d72f48a) | 参见 [PROBLEM: repeated remap_file_pages on tmpfs triggers bug on process exit](https://lkml.org/lkml/2014/7/14/335) | v1 ☑✓ 3.16-rc7 | [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c118678bc79e8241f9d3434d9324c6400d72f48a) |
| 2014/5/8 | Konstantin Khlebnikov <koct9i@gmail.com> | [mm: FAULT_AROUND_ORDER patchset performance data for powerpc](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c118678bc79e8241f9d3434d9324c6400d72f48a) | Kirill A. Shutemov 在 [commit 8c6e50b029 ("mm: introduce vm_ops->map_pages()")](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=1fdb412bd825998efbced3a16f6ce7e0329728cf) 尝试围绕缺页异常的地址预读更多的文件页面, 以此减少 minor page faults 的数量.<br>1. 本补丁创建基础设施, 通过 mm/Kconfig 修改 FAULT_AROUND_ORDER 的值. 这将使体系结构维护者能够基于该体系结构的性能数据来决定合适的 FAULT_AROUND_ORDER 值(默认为 4).<br>2. 列出 powerpc (平台 pseries) 的性能数字, 并对 powerpc 的 pseries 平台进行初始化. | v1 ☑✓ 3.16-rc7 | [LKML V4,0/2](https://www.lkml.org/lkml/2014/5/8/118) |
## 6.3 DirtyPage
-------
@@ -2549,6 +2568,13 @@ huge page 最开始只支持 PMD 级别(基础页 4K, 则 PMD 级别为 2MB)的
进一步的, ARM64 MMU 支持一个连续位(Contiguous bit), 该位表示 TTE 是可缓存在单个 TLB 条目中的一组连续条目之一. 通过对该位的支持可以增加新的中间大页的大小. 可用的巨大页面大小取决于基本页面大小 PAGE_SIZE. 参见 [arm64: Add support for PTE contiguous bit.](https://lore.kernel.org/lkml/1450380686-20911-1-git-send-email-dwoods@ezchip.com)
[arm64: hugetlb: partial revert of 66b3923a1a0f](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff7925848b50050732ac0401e0acf27e8b241d7b)
[Revert "arm64: hugetlb: partial revert of 66b3923a1a0f"](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ab2e1b89230fa80328262c91d2d0a539a2790d6f)
[arm64: Re-enable support for contiguous hugepages](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5cd028b9d90403bf24c8bf7915ed61c7a9bfce6c)
在不使用连续页面的情况下, 大页面大小如下所示:
```cpp
@@ -2581,6 +2607,7 @@ huge page 最开始只支持 PMD 级别(基础页 4K, 则 PMD 级别为 2MB)的
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2020/12/05 | Andi Kleen <ak@linux.intel.com> | [mm: support more pagesizes for MAP_HUGETLB/SHM_HUGETLB](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42d7395feb56f0655cd8b68e06fc6063823449f8) | Free page reporting 只支持伙伴系统中的页面, 它不能报告为 hugetlbfs 预留的页面. 这个补丁在 hugetlb 的空闲列表中增加了对报告巨大页的支持, 它可以被 virtio_balloon 驱动程序用于内存过载和预归零空闲页, 以加速内存填充和页面错误处理. | v7 ☑ 3.8-rc1 | [LWN v7](https://lwn.net/Articles/533650), [LORE v7](https://lore.kernel.org/lkml/1352157848-29473-2-git-send-email-andi@firstfloor.org), [COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=42d7395feb56f0655cd8b68e06fc6063823449f8) |
| 2015/12/17 | David Woods <dwoods@ezchip.com> | [arm64: Add support for PTE contiguous bit.](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=66b3923a1a0f77a563b43f43f6ad091354abbfe9) | 引入 hugetlb cgroup | v5 ☑ 4.5-rc1 | [LKML v5](https://lore.kernel.org/lkml/1450380686-20911-1-git-send-email-dwoods@ezchip.com) |
| 2017/08/22 | Punit Agrawal <punit.agrawal@arm.com> | [arm64: Enable contiguous pte hugepage support](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=828f193dd62a40ade5ea8b24cb8b0a22c30df673) | 20170822104249.2189-1-punit.agrawal@arm.com | v7 ☑✓ 4.14-rc1 | [LORE v7,0/9](https://lore.kernel.org/all/20170822104249.2189-1-punit.agrawal@arm.com) |
### 7.1.5 HugeTLB CGROUP
@@ -3895,7 +3922,7 @@ Intel 的吴峰光 [PMEM NUMA node and hotness accounting/migration](https://lor
| 2021/04/15 | Tim Chen <tim.c.chen@linux.intel.com> | [Manage the top tier memory in a tiered memory](https://lore.kernel.org/patchwork/cover/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 <dave.hansen@linux.intel.com><br>Huang Ying <ying.huang@intel.com> | [Migrate Pages in lieu of discard](https://lore.kernel.org/patchwork/cover/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 <ying.huang@intel.com> | [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 中.<br>优化 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/cover/1393431)<br>*-*-*-*-*-*-*-* <br>[PatchWork -V8,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20210914013701.344956-1-ying.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork -V9,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211008083938.1702663-1-ying.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork -V10,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211116013522.140575-1-ying.huang@intel.com) |
| 2022/02/21 | Huang Ying <ying.huang@intel.com> | [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 v1,0/3](https://lore.kernel.org/r/20220221084529.1052339-1-ying.huang@intel.com) |
| 2022/02/21 | Huang Ying <ying.huang@intel.com> | [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) |
| 2021/11/24 | Hasan Al Maruf <hasan3050@gmail.com> | [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 延迟, 并损害应用程序性能. 在这个补丁集中,<br>1. 通过增强现有的 AutoNUMA 机制, 将页面从慢级节点提升到顶级节点.<br>2. 将顶级节点的回收和分配逻辑解耦, 以便回收在更高的水印处触发, 并将较冷的页面降级到慢层内存中. 因此, 顶级节点可以保留一些空闲空间, 以接受来自慢级节点的新分配和提升.<br>在对页面升级期间, 添加滞后性, 只升级那些在短时间内不太可能被降级页面. 这减少了页面在短时间内频繁降级和提升而在 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 <baolin.wang@linux.alibaba.com> | [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) |
@@ -4384,6 +4411,7 @@ DAMON 利用两个核心机制 : **基于区域的采样**和**自适应区域
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2021/08/13 | Xiongwei Song <sxwjean@gmail.com> | [Use generic code for randomization of virtual address of x86](https://patchwork.kernel.org/project/linux-mm/cover/20211011143150.318239-1-sxwjean@me.com) | ASLR 的重构. | v1 ☐ | [PatchWork v2,0/6](https://patchwork.kernel.org/project/linux-mm/cover/20211011143150.318239-1-sxwjean@me.com) |
| 2017/09/03 | Ard Biesheuvel <ard.biesheuvel@linaro.org> | [implement KASLR for ARM](https://lwn.net/Articles/732891) | ARM 支持 KASLR. | v1 ☐ | [LWN](https://lwn.net/Articles/732891)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2,0/6](https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm-kaslr-latest) |
| 2016/01/26 | Ard Biesheuvel <ard.biesheuvel@linaro.org> | [arm64: implement support for KASLR](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=2b5fe07a78a09a32002642b8a823428ade611f16) | 支持 ARM64 KASLR | v4 ☐☑✓ 4.6-rc1 | [LORE v4,0/22](https://lore.kernel.org/all/1453828249-14467-1-git-send-email-ard.biesheuvel@linaro.org) |
* 随机函数偏移(FGKASLR)
study/kernel/00-DESCRIPTION/SCHEDULER.md
+8
View File
@@ -1475,6 +1475,8 @@ Oracle 数据库具有类似的虚拟化功能, 称为 Oracle Multitenant, 其
[Linux 5.18 Scheduler Change To Further Boost AMD EPYC Performance For Some Workloads](https://www.phoronix.com/scan.php?page=news_item&px=AMD-Linux-5.18-Sched-Zen-LLC)
[Benchmarking The AMD EPYC Speed Boost Coming To Linux 5.18, Thanks To Scheduler/NUMA Improvement](https://www.phoronix.com/scan.php?page=article&item=linux-imbalance-epyc&num=1) 中在 AMD EPYC 上进行了性能测试.
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:----:|:---:|:----------:|:---:|
| 2021/12/01 | Mel Gorman <mgorman@techsingularity.net> | [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 共享缓存, 这种方法就不太理想了. 本系列解决了两个问题:<br>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)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/2](https://lore.kernel.org/lkml/20211210093307.31701-1-mgorman@techsingularity.net)<br>*-*-*-*-*-*-*-* <br>[LORE v6,0/2](https://lore.kernel.org/all/20220208094334.16379-1-mgorman@techsingularity.net) |
@@ -1772,6 +1774,12 @@ schedtune 与 uclamp 都是由 ARM 公司的 Patrick Bellasi 主导开发.
| 低时延设定 | 通过 prefer-idle 设置 | 通过 latency_sensitive 设定 |
| RT TASK | NA | 支持 |
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:-----:|:----:|:----:|:----:|:------------:|:----:|
| 2019/06/21 | Patrick Bellasi <patrick.bellasi@arm.com> | [Add utilization clamping support](https://lore.kernel.org/all/20190621084217.8167-1-patrick.bellasi@arm.com) | 20190621084217.8167-1-patrick.bellasi@arm.com | v10 ☐☑✓ | [LORE v10,0/16](https://lore.kernel.org/all/20190621084217.8167-1-patrick.bellasi@arm.com) |
| 2019/08/22 | Patrick Bellasi <patrick.bellasi@arm.com> | [Add utilization clamping support (CGroups API)](https://lore.kernel.org/all/20190822132811.31294-1-patrick.bellasi@arm.com) | 20190822132811.31294-1-patrick.bellasi@arm.com | v14 ☐☑✓ | [LORE v14,0/6](https://lore.kernel.org/all/20190822132811.31294-1-patrick.bellasi@arm.com) |
## 7.6 freezer 冻结
-------