mirror of
https://github.com/gatieme/LDD-LinuxDeviceDrivers.git
synced 2026-10-14 00:53:24 +08:00
description/memory: update patchwork series to 20220723
This commit is contained in:
@@ -3836,8 +3836,7 @@ v2.5 的时候引入了 shrink 机制, 并提供了 API 统一了各个模块的
|
||||
|:----:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2018/07/03 | Kirill Tkhai <ktkhai@virtuozzo.com> | [Improve shrink_slab() scalability (old complexity was O(n^2), new is O(n))](https://lore.kernel.org/all/153063036670.1818.16010062622751502.stgit@localhost.localdomain/) | 降低 shrink_slab 的算法复杂度, 从 O(N^2) 降低到 O(N). | v8 ☑ 4.19-rc1 | [LORE v8,00/17](https://lore.kernel.org/all/153063036670.1818.16010062622751502.stgit@localhost.localdomain), [LORE v9,00/17](https://lore.kernel.org/all/153112469064.4097.2581798353485457328.stgit@localhost.localdomain) |
|
||||
| 2018/08/07 | Kirill Tkhai <ktkhai@virtuozzo.com> | [ 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 <hdanton@sina.com> | [[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) |
|
||||
| 2022/04/02 | Hillf Danton <hdanton@sina.com> | [[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) |
|
||||
|
||||
|
||||
## 4.4 主动的页面回收(Proactive Reclaim)
|
||||
@@ -5020,7 +5019,7 @@ swap out 的时候打散, swap in 的时候可能又需要重新聚合回来,
|
||||
|:----:|:----:|:---:|:----:|:---------:|:----:|
|
||||
| 2017/05/15 | "Huang, Ying" <ying.huang@intel.com> | [THP swap: Delay splitting THP during swapping out/STEP 1](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=747552b1e71b400fa32a221e072be2c0b7661f14) | 在这个补丁集完成了延迟拆分 THP, 将拆分大页面的时间几乎从交换的第一步推迟到为 THP 分配交换空间并将 THP 添加到交换缓存之后. 这将减少交换缓存管理中使用的锁的获取/释放.<br>在 8 个进程的 vm-scalability swap-w-seq 测试用例(测试用例创建了 8 个进程, 它们依次分配和写入匿名页面, 直到 RAM 和交换设备的一部分用完)中, 使用补丁集, 换出的吞吐量提高了 15.5%(从 3.73GB/s 提高到 4.31GB/s). | v11 ☑ 4.13-rc1 | [2016/08/09 LORE RFC,00/11](https://lore.kernel.org/lkml/1470760673-12420-1-git-send-email-ying.huang@intel.com)[2016/09/01 LORE v2,00/10](https://lore.kernel.org/lkml/1472743023-4116-1-git-send-email-ying.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,00/12](https://lore.kernel.org/all/20170724051840.2309-1-ying.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[2017/05/15 LORE v11,0/5](https://lore.kernel.org/lkml/20170515112522.32457-1-ying.huang@intel.com) |
|
||||
| 2017/07/14 | "Huang, Ying" <ying.huang@intel.com> | [THP swap: Delay splitting THP during swapping out/STEP 2](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=fe490cc0fe9e6ee48cc48bb5dc463bc5f0f1428f) | 这是 THP (透明大页) 交换优化的 STEP 2. 在 STEP 1, 拆分大页面的时机从交换的第一步延迟到为 THP 分配交换空间并将 THP 添加到交换缓存之后. 在 STEP 2 中, 拆分被进一步延迟到交换完成之后. 在这个补丁集中, 对匿名 THP 回收的更多操作(如 TLB 刷新、将 THP 写入交换设备、将 THP 从交换缓存中删除) 被批处理. 从而提高了匿名 THP 交换的性能. | v3 ☑ 4.14-rc1 | [2017/06/23 LORE v2,00/12](https://lore.kernel.org/lkml/20170623071303.13469-1-ying.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[2017/07/24 LORE v3,00/12](https://lore.kernel.org/all/20170724051840.2309-1-ying.huang@intel.com) |
|
||||
| 2022/05/27 | Barry Song <21cnbao@gmail.com> | [[v2] arm64: enable THP_SWAP for arm64](https://patchwork.kernel.org/project/linux-mm/patch/20220527100644.293717-1-21cnbao@gmail.com/) | 645555 | v2 ☐☑ | [LORE v2](https://lore.kernel.org/r/20220527100644.293717-1-21cnbao@gmail.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3](https://lore.kernel.org/r/20220706072707.114376-1-21cnbao@gmail.com) |
|
||||
| 2022/05/27 | Barry Song <21cnbao@gmail.com> | [[v2] arm64: enable THP_SWAP for arm64](https://patchwork.kernel.org/project/linux-mm/patch/20220527100644.293717-1-21cnbao@gmail.com/) | 645555 | v2 ☐☑ | [LORE v2](https://lore.kernel.org/r/20220527100644.293717-1-21cnbao@gmail.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3](https://lore.kernel.org/r/20220706072707.114376-1-21cnbao@gmail.com)<br>*-*-*-*-*-*-*-* <br>[LORE v4,0/1](https://lore.kernel.org/r/20220720093737.133375-1-21cnbao@gmail.com) |
|
||||
|
||||
|
||||
* Swapout/swapin THP in one piece
|
||||
@@ -6127,7 +6126,7 @@ Intel 的吴峰光 [PMEM NUMA node and hotness accounting/migration](https://lor
|
||||
| 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) |
|
||||
| 2022/07/13 | Huang Ying <ying.huang@intel.com> | [memory tiering: hot page selection](https://patchwork.kernel.org/project/linux-mm/cover/20220408071222.219689-1-ying.huang@intel.com/) | 在分级内存的系统中, 需要使用 NUMA 来优化页面在内存中的位置. 基本上, 最初的 NUMA Balancing 实现选择并提升最近访问最多(mostly recently accessed/MRU)的页面. 但最近访问的页面可能很冷. 因此, 在这个补丁集中, 我们基于 NUMA 平衡页表扫描和页面 Page Fault & Hint 之间的延迟实现了一个新的热页识别算法. 另外一方面热页升级可能会在系统中产生一些开销. 为了控制开销, 实现了一种简单的提升速率限制机制. 用于识别热页的热阈值通常取决于工作负载. 因此, 我们还实现了一个热页阈值自动调整算法. 基本思想是增加/减少热页阈值, 使通过热页阈值提升到快速内存的页面数接近速率限制. | v1 ☐☑ | [2022/04/08 LORE v1,0/3](https://lore.kernel.org/r/20220408071222.219689-1-ying.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[2022/06/22 LORE v1,0/3](https://lore.kernel.org/r/20220622083519.708236-1-ying.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[2022/07/13 LORE v1,0/3](https://lore.kernel.org/r/20220713083954.34196-1-ying.huang@intel.com) |
|
||||
| 2022/04/13 | Jagdish Gediya <jvgediya@linux.ibm.com> | [mm: demotion: Introduce new node state N_DEMOTION_TARGETS](https://patchwork.kernel.org/project/linux-mm/cover/20220413092206.73974-1-jvgediya@linux.ibm.com/) | 631805 | v2 ☐☑ | [LORE v2,0/5](https://lore.kernel.org/r/20220413092206.73974-1-jvgediya@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v3,0/7](https://lore.kernel.org/r/20220422195516.10769-1-jvgediya@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/3](https://lore.kernel.org/r/20220426085105.60822-1-ying.huang@intel.com)<br>*-*-*-*-*-*-*-* <br>[LORE v1,0/3](https://lore.kernel.org/r/20220510063958.86985-1-ying.huang@intel.com) |
|
||||
| 2022/07/14 | Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> | [mm/demotion: Memory tiers and demotion](https://patchwork.kernel.org/project/linux-mm/cover/20220527122528.129445-1-aneesh.kumar@linux.ibm.com/) | 645595 | v4 ☐☑ | [LORE v4,0/7](https://lore.kernel.org/r/20220527122528.129445-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/9](https://lore.kernel.org/r/20220603134237.131362-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v6,0/13](https://lore.kernel.org/r/20220610135229.182859-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/12](https://lore.kernel.org/r/20220622082513.467538-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v9,0/8](https://lore.kernel.org/r/20220714045351.434957-1-aneesh.kumar@linux.ibm.com) |
|
||||
| 2022/07/14 | Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> | [mm/demotion: Memory tiers and demotion](https://patchwork.kernel.org/project/linux-mm/cover/20220527122528.129445-1-aneesh.kumar@linux.ibm.com/) | 645595 | v4 ☐☑ | [LORE v4,0/7](https://lore.kernel.org/r/20220527122528.129445-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v5,0/9](https://lore.kernel.org/r/20220603134237.131362-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v6,0/13](https://lore.kernel.org/r/20220610135229.182859-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v7,0/12](https://lore.kernel.org/r/20220622082513.467538-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v9,0/8](https://lore.kernel.org/r/20220714045351.434957-1-aneesh.kumar@linux.ibm.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/8](https://lore.kernel.org/r/20220720025920.1373558-1-aneesh.kumar@linux.ibm.com) |
|
||||
| 2022/06/06 | Aneesh Kumar K V <aneesh.kumar@linux.ibm.com> | [mm/demotion: Add sysfs ABI documentation](https://patchwork.kernel.org/project/linux-mm/patch/87r1428k9n.fsf@linux.ibm.com/) | 647508 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/87r1428k9n.fsf@linux.ibm.com) |
|
||||
| 2022/06/07 | Johannes Weiner <hannes@cmpxchg.org> | [mm: mempolicy: N:M interleave policy for tiered memory nodes](https://patchwork.kernel.org/project/linux-mm/patch/20220607171949.85796-1-hannes@cmpxchg.org/) | 648110 | v1 ☐☑ | [LORE v1,0/1](https://lore.kernel.org/r/20220607171949.85796-1-hannes@cmpxchg.org) |
|
||||
| 2022/06/14 | Tim Chen <tim.c.chen@linux.intel.com> | [Cgroup accounting of memory tier usage](https://patchwork.kernel.org/project/linux-mm/cover/cover.1655242024.git.tim.c.chen@linux.intel.com/) | 650358 | v1 ☐☑ | [LORE v1,0/3](https://lore.kernel.org/r/cover.1655242024.git.tim.c.chen@linux.intel.com) |
|
||||
|
||||
Reference in New Issue
Block a user