mirror of
https://github.com/gatieme/LDD-LinuxDeviceDrivers.git
synced 2026-08-17 16:52:08 +08:00
description/open_source: update phoronix vs LWN to date 20241115
This commit is contained in:
Cheng Jian
@@ -133,6 +133,19 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
|
||||
|
||||
[群魔乱舞：MoE大模型详解](https://www.zhihu.com/tardis/bd/art/677638939)
|
||||
|
||||
[【论文阅读】MOE，《OUTRAGEOUSLY LARGE NEURAL NETWORKS: THE SPARSELY-GATED MIXTURE-OF-EXPERTS LAYER》](https://blog.csdn.net/bylander/article/details/138139345)
|
||||
|
||||
[【论文速读】MOD，《Mixture-of-Depths: Dynamically allocating compute in transformer-based language models》](https://blog.csdn.net/bylander/article/details/139536003)
|
||||
|
||||
[Mixture of Depths论文解读](https://zhuanlan.zhihu.com/p/691324301)
|
||||
|
||||
[OLMoE](https://github.com/allenai/OLMoE)
|
||||
|
||||
### 2.2.2 稀疏化训练
|
||||
-------
|
||||
|
||||
[【ICDE 2022】阿里发布稀疏模型训练框架HybridBackend，单位成本下训练吞吐提升至5倍](https://blog.csdn.net/weixin_48534929/article/details/124661176)
|
||||
|
||||
|
||||
## 2.3 模型压缩和量化
|
||||
-------
|
||||
@@ -188,9 +201,11 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
|
||||
-------
|
||||
|
||||
|
||||
[LLM推理加速技术简介](https://zhuanlan.zhihu.com/p/691360124)
|
||||
[知乎--LLM推理加速技术简介](https://zhuanlan.zhihu.com/p/691360124)
|
||||
|
||||
[bilibili--如何将大模型与小模型结合？这8种常用策略必看！附17篇案例论文和代码](https://www.bilibili.com/opus/887920175625535524)
|
||||
|
||||
[知乎--刀刀宁聊大模型推理--笔记：学习推理加速半年之总结与迷思](https://zhuanlan.zhihu.com/p/704938096)
|
||||
|
||||
### 4.2.1 KV Cache 压缩
|
||||
-------
|
||||
@@ -207,6 +222,44 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
|
||||
[聊聊大模型推理中的 KVCache 压缩](https://zhuanlan.zhihu.com/p/708946312)
|
||||
|
||||
|
||||
### 4.2.2 稀疏感知推理加速
|
||||
-------
|
||||
|
||||
[论文笔记：DejaVu、LLM in Flash、PowerInfer](https://zhuanlan.zhihu.com/p/675585887)
|
||||
|
||||
[苹果极致LLM端侧方案：LLM in a flash](https://zhuanlan.zhihu.com/p/673775476)
|
||||
|
||||
### 4.2.3 首 Token 时延优化
|
||||
-------
|
||||
|
||||
[[Prefill优化][万字]🔥原理&图解vLLM Automatic Prefix Cache(RadixAttention): 首Token时延优化](https://zhuanlan.zhihu.com/p/693556044)
|
||||
|
||||
### 4.2.4 投机执行
|
||||
-------
|
||||
|
||||
[论文导读 | 投机解码加速模型推理](https://zhuanlan.zhihu.com/p/698333087)
|
||||
|
||||
[大模型推理妙招—投机采样(Speculative Decoding)](https://zhuanlan.zhihu.com/p/651359908)
|
||||
|
||||
[最全LLM自投机算法汇总](https://zhuanlan.zhihu.com/p/706111755)
|
||||
|
||||
[LLM推理提速2.8倍，CMU清华姚班校友提出「投机式推理」引擎SpecInfer，小模型撬动大模型高效推理](https://www.jiqizhixin.com/articles/2023-05-30-3)
|
||||
|
||||
|
||||
## 4.3 算子库
|
||||
-------
|
||||
|
||||
|
||||
PaddlePaddle/Anakin
|
||||
|
||||
Tencent/ncnn
|
||||
|
||||
Tencent/FeatherCNN
|
||||
|
||||
dmlc/tvm
|
||||
|
||||
ARM-software/ComputeLibrary
|
||||
|
||||
# 5 分析工具
|
||||
-------
|
||||
|
||||
@@ -292,6 +345,11 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
|
||||
| [HqWu-HITCS/Awesome-Chinese-LLM](https://github.com/HqWu-HITCS/Awesome-Chinese-LLM) | 整理开源的中文大语言模型, 主要关注规模较小, 可私有化部署, 训练成本较低的模型. 包括底座模型, 垂直领域微调以及应用, 数据集合教程等内容 |
|
||||
| [km1994/nlp_paper_study](https://github.com/km1994/nlp_paper_study) | 该仓库主要记录 NLP 算法工程师相关的顶会论文研读笔记. |
|
||||
| [NexaAI/Awesome-LLMs-on-device](https://github.com/NexaAI/Awesome-LLMs-on-device) | 汇总了端侧 AI 的相关架构和优化技术, 包括前言的论文研究. |
|
||||
| [wdndev/llm_interview_note](https://github.com/wdndev/llm_interview_note) | 主要记录大语言大模型(LLMs) 算法(应用)工程师相关的知识及面试题. |
|
||||
| [冬于的博客-Transformer/BERT/实战](https://ifwind.github.io/2021/08/31/Transformer-BERT-实战) | 通过大量图讲述 Transformer 架构 |
|
||||
| [浅显易懂地介绍 llm.c [译]](https://baoyu.io/translations/llm/explaining-llm-c-in-layman-terms) | [Explainable Language Models: Existing and Novel Approaches](https://twitter.com/karpathy/status/1778153659106533806) 的译文, 参见 [karpathy/llm.c](https://github.com/karpathy/llm.c). |
|
||||
| [DefTruth/Awesome-LLM-Inference](https://github.com/DefTruth/Awesome-LLM-Inference) | 收集了大量 LLM 推理相关的论文和仓库, 涵盖了并行计算, 量化压缩, 注意力机制优化, 上下文管理等. |
|
||||
| [SylphAI-Inc/llm-engineer-handbook](https://github.com/SylphAI-Inc/llm-engineer-handbook) | NA |
|
||||
|
||||
|
||||
## 6.2 Survey
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -441,7 +441,7 @@ raw_tracepoint 相比 tracepoint
|
||||
| 2021/06/19 | Alan Maguire <alan.maguire@oracle.com> | [libbpf: BTF dumper support for typed data](https://lore.kernel.org/patchwork/cover/1448989) | 引入 btf_dump__dump_type_data, 可以用来输出结构体的信息. | v5 ☐ | [PatchWork v5,bpf-next,0/3](https://lore.kernel.org/patchwork/cover/1448989) |
|
||||
|
||||
|
||||
## 3.1 5 function call
|
||||
## 3.1 function call
|
||||
-------
|
||||
|
||||
[Calling kernel functions from BPF](https://lwn.net/Articles/856005)
|
||||
@@ -654,7 +654,7 @@ Wasmtime 完全开源, 使用 Rust 编程语言, 是的, 并且符合 WASI 标
|
||||
| [apache/skywalking-rover](https://github.com/apache/skywalking-rover) | |
|
||||
| [GroundCover](https://github.com/groundcover-com) | [GroundCover](https://www.groundcover.com) 轻松、大规模地监控 K8s 应用 |
|
||||
| [Exein-io/pulsar](https://github.com/Exein-io/pulsar) | [Tracing the Linux kernel using Exein Pulsar: a 5 Minute Tutorial](https://blog.exein.io/pulsar-tutorial)
|
||||
| [ebpf-for-windows](https://github.com/microsoft/ebpf-for-windows) | [eBPF programming on Windows](https://blog.subcom.tech/ebpf-programming-on-windows). |
|
||||
| [ebpf-for-windows](https://github.com/microsoft/ebpf-for-windows) | [eBPF programming on Windows](https://blog.subcom.tech/ebpf-programming-on-windows)<br>*-*-*-*-*-*-*-*<br>[eBPF Is Coming for Windows](https://thenewstack.io/ebpf-is-coming-for-windows). |
|
||||
| [redcanaryco/ebpfmon](https://github.com/redcanaryco/ebpfmon) | [eBPFmon: A new tool for exploring and interacting with eBPF applications](https://redcanary.com/blog/ebpfmon) |
|
||||
| [TrailOfBits](https://github.com/trailofbits) | [Trail of Bits 开发了一套开源库, 旨在简化 eBPF 应用程序的创建和部署. 这些库有助于高效的进程和网络事件监控、函数跟踪、内核调试符号解析和 eBPF 代码生成. 参见 [Use our suite of eBPF libraries](https://blog.trailofbits.com/2023/08/09/use-our-suite-of-ebpf-libraries). |
|
||||
| [Netflix/bpftop](https://github.com/Netflix/bpftop) | [bpftop blog](https://netflixtechblog.com/announcing-bpftop-streamlining-ebpf-performance-optimization-6a727c1ae2e5)
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -320,6 +320,9 @@ Google 的 Joel Fernandes 等发现 RCU 并没有很好的节能, 在 Android
|
||||
|
||||
[内核工匠-futex问答](https://blog.csdn.net/feelabclihu/article/details/127020166)
|
||||
|
||||
[性能打磨手记：记一段 Futex 机制的内核优化之旅](https://kernel.meizu.com/2024/03/15/Futex机制的内核优化)
|
||||
|
||||
[FUTEX_SWAP补丁分析-SwitchTo 如何大幅度提升切换性能？](https://blog.csdn.net/21cnbao/article/details/118980971)
|
||||
|
||||
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|
||||
|:---:|:----:|:---:|:----:|:---------:|:----:|
|
||||
@@ -485,7 +488,7 @@ Proxy Execution 是一种通用形式的优先级继承机制, 它旨在解决
|
||||
| 2022/10/03 | Connor O'Brien <connoro@google.com> | [Reviving the Proxy Execution Series](https://lore.kernel.org/all/20221003214501.2050087-1-connoro@google.com) | TODO | v1 ☐☑✓ | [2022/10/03 LORE v1,0/11](https://lore.kernel.org/all/20221003214501.2050087-1-connoro@google.com)<br>*-*-*-*-*-*-*-* <br>[2023/03/20 LORE v2,0/12](https://lore.kernel.org/all/20230320233720.3488453-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2023/04/11 LORE v3,00/14](https://lore.kernel.org/all/20230411042511.1606592-1-jstultz@google.com) |
|
||||
| 2023/06/01 | John Stultz <jstultz@google.com> | [Generalized Priority Inheritance via Proxy Execution](https://lore.kernel.org/all/20230601055846.2349566-1-jstultz@google.com) | TODO | v3 ☐☑✓ | [LORE v4,0/13](https://lore.kernel.org/all/20230601055846.2349566-1-jstultz@google.com) |
|
||||
| 2023/12/19 | John Stultz <jstultz@google.com> | [Proxy Execution: A generalized form of Priority Inheritance v7](https://lore.kernel.org/all/20231220001856.3710363-1-jstultz@google.com) | TODO | v7 ☐☑✓ | [2023/12/19, LORE v7,0/23](https://lore.kernel.org/all/20231220001856.3710363-1-jstultz@google.com) |
|
||||
| 2024/05/06 | John Stultz <jstultz@google.com> | [Preparatory changes for Proxy Execution](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=af0c8b2bf67b25756f27644936e74fd9a6273bd2) | Proxy Execution 是一种通用的优先级继承机制的实现方法, 用于解决优先级反转问题和其他类似的问题. 这些预备补丁的目的是为后续更复杂的 Proxy Execution 相关补丁打下基础.<br>在发送第 7 版 Proxy Execution 补丁集时, John Stultz 收到了反馈, 指出补丁集变得过于庞大难以审查. 因此, 根据 Qais Yousef 的建议, 他决定将补丁集分为两部分：一部分是预备性的更改, 另一部分是更复杂的功能实现. 参见 [phoronix, 2024/10/18, Linux 6.13 Poised To Land Prep Patches Working Toward Proxy Execution](https://www.phoronix.com/news/Linux-6.13-Prep-For-Proxy-Exec#google_vignette). | v10 ☐☑✓ v6.13-rc1 | [2024/02/24, LORE v8,0/7](https://lore.kernel.org/all/20240224001153.2584030-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/04/01, LORE v9,0/7](https://lore.kernel.org/all/20240401234439.834544-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/7](https://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/07/09, LORE v11,0/7](https://lore.kernel.org/all/20240709203213.799070-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/08/13, LORE v12,0/7](https://lore.kernel.org/all/20240813235736.1744280-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/08/29, RESEND, LORE v12,0/7](https://lore.kernel.org/all/20240829225212.6042-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/10/09, RESEND x3, LORE v12,0/7](https://lore.kernel.org/all/20241009235352.1614323-1-jstultz@google.com) |
|
||||
| 2024/05/06 | John Stultz <jstultz@google.com> | [Preparatory changes for Proxy Execution](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=af0c8b2bf67b25756f27644936e74fd9a6273bd2) | Proxy Execution 是一种通用的优先级继承机制的实现方法, 用于解决优先级反转问题和其他类似的问题. 这些预备补丁的目的是为后续更复杂的 Proxy Execution 相关补丁打下基础.<br>在发送第 7 版 Proxy Execution 补丁集时, John Stultz 收到了反馈, 指出补丁集变得过于庞大难以审查. 因此, 根据 Qais Yousef 的建议, 他决定将补丁集分为两部分：一部分是预备性的更改, 另一部分是更复杂的功能实现. 参见 [phoronix, 2024/10/18, Linux 6.13 Poised To Land Prep Patches Working Toward Proxy Execution](https://www.phoronix.com/news/Linux-6.13-Prep-For-Proxy-Exec). | v10 ☐☑✓ v6.13-rc1 | [2024/02/24, LORE v8,0/7](https://lore.kernel.org/all/20240224001153.2584030-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/04/01, LORE v9,0/7](https://lore.kernel.org/all/20240401234439.834544-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[LORE v10,0/7](https://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/07/09, LORE v11,0/7](https://lore.kernel.org/all/20240709203213.799070-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/08/13, LORE v12,0/7](https://lore.kernel.org/all/20240813235736.1744280-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/08/29, RESEND, LORE v12,0/7](https://lore.kernel.org/all/20240829225212.6042-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/10/09, RESEND x3, LORE v12,0/7](https://lore.kernel.org/all/20241009235352.1614323-1-jstultz@google.com) |
|
||||
| 2024/02/02 | Metin Kaya <metin.kaya@arm.com> | [sched: Add trace events for Proxy Execution (PE)](https://lore.kernel.org/all/20240202083338.1328060-1-metin.kaya@arm.com) | 添加 `sched_[start，finish]_task_selection` 跟踪事件以测量 PE 补丁在任务选择中的延迟. 此外, 在 PE 中引入有趣事件的跟踪事件:<br>1. sched_pe_enque_sleeping_task: 一个任务在睡眠任务(互斥体所有者)的等待队列中排队.<br>2. sched_pe_cross_mote_cpu: 依赖链跨远程 cpu.<br>3. sched_pe_task_is_migration: 互斥所有者任务迁移. 可以通过以下命令测试新的跟踪事件: `perf record -e sched:sched_start_task_selection -e sched:sched_finish_task_selection -e sched:sched_pe_enque_sleeping_task -e sched:sched_pe_cross_mote_cpu -e sched:sched_pe_task_is_migration`. 此补丁基于 John 的 [Proxy Execution v7 补丁系列](https://lore.kernel.org/linux-kernel/CANDhNCrHd+5twWVNqBAhVLfhMhkiO0KjxXBmwVgaCD4kAyFyWw@mail.gmail.com). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240202083338.1328060-1-metin.kaya@arm.com) |
|
||||
| 2024/11/05 | John Stultz <jstultz@google.com> | [Single CPU Proxy Execution (v13)](https://lore.kernel.org/all/20241106025656.2326794-1-jstultz@google.com) | 这组补丁的主要目的是实现单 CPU 代理执行(Single CPU Proxy Execution)机制, 这是一种通用形式的优先级继承(priority inheritance)方法, 旨在解决某些特定场景下的调度问题.<br>1. 实现单 CPU 代理执行机制, 支持作为构建和运行时选项.<br>2. 重新设计互斥锁的 blocked_on 结构, 以便更好地支持代理执行.<br>3. 处理代理执行带来的假设变化, 确保调度器的正确性.<br>4. 实现初始逻辑, 使锁持有者可以在同一 CPU 上代替等待任务运行.<br>通过这些改动, 调度器在处理某些特定场景下的优先级继承问题时更加高效和灵活, 提高了系统的整体性能和响应速度. 参见 [Paper](https://static.lwn.net/images/conf/rtlws11/papers/proc/p38.pdf) | v13 ☐☑✓ | [LORE v13,0/7](https://lore.kernel.org/all/20241106025656.2326794-1-jstultz@google.com)<br>*-*-*-*-*-*-*-* <br>[2024/11/25, LORE v14,0/7](https://lore.kernel.org/all/20241125195204.2374458-1-jstultz@google.com) |
|
||||
|
||||
@@ -540,6 +543,8 @@ SCaLE 21x 上 Alison Chaiken 关于 WorkQueue 的讨论, 参见 [Diagnosing work
|
||||
| 2024/02/16 | Tejun Heo <tj@kernel.org> | [workqueue: Implement disable/enable_work()](https://lore.kernel.org/all/20240216180559.208276-1-tj@kernel.org) | [Linux 6.9 Sees Invasive & Significant Changes To Workqueues](https://www.phoronix.com/news/Linux-6.9-Workqueue). | v1 ☐☑✓ | [LORE](https://lore.kernel.org/all/20240216180559.208276-1-tj@kernel.org) |
|
||||
| 2024/01/29 | Tejun Heo <tj@kernel.org> | [workqueue: Introduce struct wq_node_nr_active](https://lore.kernel.org/all/Zbfq8egWUfYgkOsa@slm.duckdns.org) | TODO | v4 ☐☑✓ | [LORE v4,0/10](https://lore.kernel.org/all/Zbfq8egWUfYgkOsa@slm.duckdns.org) |
|
||||
| 2024/06/22 | Leonardo Bras <leobras@redhat.com> | [Introduce QPW for per-cpu operations](https://lore.kernel.org/all/20240622035815.569665-1-leobras@redhat.com) | 提出一种 QPW(Queue PerCPU Work) 作为在 PREEMPT_RT 内核中处理每个 CPU 操作的更好方法, 以取代工作队列 WorkQueue.<br>目前使用 PREEMPT_RT=y, local_locks() 变成了每个 CPU 的自旋锁. 在这种情况下, 不需要在远程 CPU 上调度工作, 尝试获取远程 CPU 的每个 CPU 自旋锁并在本地运行所需的工作应该是安全的, 主要的代价是在每个局部函数中执行 un/locking.<br>引入 queue_percpu_work_on() API, 在非 PREEMPT_RT 内核上的现有 local_locks 和 WorkQueue 的行为进行包装. 但对于 PREEMPT_RT 的内核, QPW 将锁定 CPU 的每个 CPU 结构并在本地执行工作. 参见 [Red Hat Proposes Queue PerCPU Work "QPW" For Better Handling Per-CPU Work On RT Linux](https://www.phoronix.com/news/Linux-Queue-Per-CPU-Work-QPW). | v1 ☐☑✓ | [LORE v1,0/4](https://lore.kernel.org/all/20240622035815.569665-1-leobras@redhat.com) |
|
||||
| 2024/09/23 | Chen Ridong <chenridong@huaweicloud.com> | [add dedicated wq for cgroup bpf and adjust WQ_MAX_ACTIVE](https://lore.kernel.org/all/20240923114352.4001560-1-chenridong@huaweicloud.com) | 这组补丁的主要目的是为 cgroup BPF 销毁操作添加一个专用的工作队列(workqueue), 并调整 WQ_MAX_ACTIVE 的默认值从 512 增加到 2048. 该补丁集旨在解决现有系统工作队列(system_wq)在处理大量 cgroup BPF 销毁请求时可能被饱和的问题, 并通过引入专用工作队列来提高性能和可靠性. 此外, 还增加了 WQ_MAX_ACTIVE 的默认值以支持更多的并发任务. 参见 [phoronix, 2024/11/18, Linux 6.13 Quadrupling Workqueue Concurrency Limit](https://www.phoronix.com/news/Linux-6.13-Workqueues) | v5 ☐☑✓ | [LORE v5,0/3](https://lore.kernel.org/all/20240923114352.4001560-1-chenridong@huaweicloud.com)<br>*-*-*-*-*-*-*-* <br>[部分合入 COMMIT](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=581434654e01ec79dd02c21448ac84e2ce2d1a64) |
|
||||
| 2024/12/11 | Frederic Weisbecker <frederic@kernel.org> | [kthread: Introduce preferred affinity v6](https://lore.kernel.org/all/20241211154035.75565-1-frederic@kernel.org) | 该补丁集的主要目的是引入内核线程(kthread)的首选亲和性(preferred affinity)机制, 以增强内核线程调度的灵活性和性能. 当前, 内核线程的 CPU 亲和性是静态设定的, 无法动态调整. 这限制了某些应用场景中对 CPU 资源的有效利用. 通过引入首选亲和性机制, 允许内核线程在启动时指定一个或多个偏好的 CPU, 并且当这些 CPU 空闲时优先运行在这些 CPU 上. 如果偏好的 CPU 不可用, 则内核线程仍可以在其他 CPU 上运行, 但会尽量回到首选的 CPU 上继续执行. 通过引入首选亲和性机制, 可以显著改善特定应用场景下的调度效率和资源利用率, 尤其是在 NUMA 系统或多核处理器上. 例如, 在网络处理、实时任务调度等场景中, 可以让关键任务尽可能地运行在其偏好的 CPU 上, 从而减少跨节点访问内存带来的延迟, 提高整体系统性能. | v6 ☐☑✓ | [LORE v6,0/19](https://lore.kernel.org/all/20241211154035.75565-1-frederic@kernel.org) |
|
||||
|
||||
|
||||
# 13 Windows NT Synchronization Primitive Driver
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -112,6 +112,9 @@
|
||||
| 6.9 | [The first half of the 6.9 merge window](https://lwn.net/Articles/965141), [Kernel prepatch 6.9-rc1](https://lwn.net/Articles/966525), [The rest of the 6.9 merge window](https://lwn.net/Articles/965541) | NA | NA |
|
||||
| 6.10 | [The first half of the 6.10 merge window](https://lwn.net/Articles/973687)<br>*-*-*-*-*-*-*-* <br>[The rest of the 6.10 merge window](https://lwn.net/Articles/974869)<br>*-*-*-*-*-*-*-* <br>[Kernel prepatch 6.10-rc2](https://lwn.net/Articles/976498). | NA | [Linux 6.10-rc1 Kernel Released With Many New Features](https://www.phoronix.com/news/Linux-6.10-rc1), [Linux 6.10-rc5 Released With This Kernel Cycle Looking Good So Far](https://www.phoronix.com/news/Linux-6.10-rc5) |
|
||||
| 6.11 | [The first half of the 6.11 merge window](https://lwn.net/Articles/982034), [LWN, 2024/07/28, Kernel prepatch 6.11-rc1](https://lwn.net/Articles/983760), [LWN, 2024/07/29, The rest of the 6.11 merge window](https://lwn.net/Articles/982605), [LWN, 2024/08/11, Kernel prepatch 6.11-rc3](https://lwn.net/Articles/985233) | NA | NA |
|
||||
| 6.12 | NA | NA | [phoronix, 2024/11/17, Linux 6.12 Released With Real-Time Capabilities, Sched_Ext, More AMD RDNA4 & More](https://www.phoronix.com/news/Linux-6.12-Released) |
|
||||
| 6.13 | NA | MA | [phoronix, 2024/12/06, Linux 6.13 Features: AutoFDO+Propeller Optimizations, Many AMD Additions & SDUC + NVMe 2.1 Support](https://www.phoronix.com/review/linux-613-features) |
|
||||
|
||||
|
||||
年终盘点
|
||||
|
||||
|
||||
File diff suppressed because one or more lines are too long
@@ -1,6 +1,4 @@
|
||||
AMD 异构内核设计和硬件反馈接口 (HFI) 为调度程序提供行为分类和动态更新的排名表, 供调度程序在为任务选择内核时使用.
|
||||
|
||||
线程在运行时被分类为枚举类. 目前, 该驱动程序支持 3 个类(0 到 2). 这些类表示可能受益于特殊调度行为的线程性能/功耗特征. 实时线程分类由操作系统使用, 用于通知计划程序应将线程放置在何处以获得最佳性能或能效.
|
||||
|
||||
线程分类有助于从排名表中选择 CPU, 该表从两个维度描述了每个分类的效率和性能排名.
|
||||
排名表提供的排名数据是 0 到 255 之间的数字, 其中性能值越高表示性能能力越高, 效率越高表示效率越高. 所有 CPU 内核都分为不同的类 ID. 在每个类排名中, 核心可能具有不同的排名值. 因此, 从每个分类 ID 中选取允许调度程序选择最佳核心, 同时将线程分类到指定的工作负载类中. 内核排名表提供了 PCCT 子空间类型 4 共享内存, 其中包括内存基址和长度.
|
||||
该补丁集的主要目的是改进 Energy Aware Scheduler (EAS) 的实现, 以更好地处理某些特定情况, 并修复已知的一些局限性, 特别是与 uclamp(利用率钳位)特性相关的场景. <br>现有问题: 当前的 EAS 实现存在一些局限性, 在引入 uclamp 等新特性后变得更加明显. 例如, 任务可能会堆积在同一个 CPU 上, 或者被卡在错误的 CPU 上无法迁移, 导致调度效率下降. <br>目标: 通过一系列改动, 确保 EAS 能够更灵活地应对不同类型的负载和调度需求, 特别是在异构多核处理器(如大小核架构)上优化性能和功耗. <br>具体改动: <br>1. 修正 CPU 过载分类问题: Patch 1 修复了当 CPU 被限制到较低的计算容量时, 可能被错误地分类为过载的问题. 这种错误分类可能导致周期性负载均衡器无法正确选择合适的 CPU 来放置任务. 通过修正这一问题, 可以避免不必要的负载均衡操作, 提高调度精度. <br>2. 创建新的 EM 接口; Patch 2 引入了一个新的能量模型(EM, Energy Model)接口, 该接口将在后续补丁中用于改进任务放置逻辑. <br>优化任务放置策略: Patch 3: 改进了任务放置策略, 使得在选择目标 CPU 时不仅考虑空闲容量最高的 CPU, 还会评估其他因素, 如运行的任务数量等. 这有助于找到真正最优的放置位置, 而不仅仅是基于单一标准. <br>进一步优化: Patch 4 和 Patch 5: 继续对 EAS 进行优化, 解决更多特定场景下的问题, 确保调度器能够在各种情况下都表现出色.
|
||||
|
||||
|
||||
@@ -795,11 +795,6 @@ https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org/
|
||||
| 3 |
|
||||
|
||||
|
||||
| 2024/10/31 | Tianchen Ding <dtcccc@linux.alibaba.com> | [sched/eevdf: Force propagating min_slice of cfs_rq when a task changing slice](https://lore.kernel.org/all/20241031094822.30531-1-dtcccc@linux.alibaba.com) | TODO | v2 ☐☑✓ | [LORE](https://lore.kernel.org/all/20241031094822.30531-1-dtcccc@linux.alibaba.com) |
|
||||
|
||||
|
||||
|
||||
|
||||
这组补丁的主要目的是让 x86 架构下的模块使用大页(large pages)来分配可执行内存(ROX pages), 以提高性能和减少 TLB(Translation Lookaside Buffer)的压力. 为 x86 架构引入对大页(通常是 2MB 或 4KB 的页面)的支持, 用于模块的文本段(代码段)分配. 修复与 kmemleak 交互的问题，并改进了与 CFI（Control Flow Integrity）配置的兼容性.
|
||||
添加了一个新的 Kconfig 选项 ARCH_HAS_EXECMEM_ROX，确保架构实现 execmem_fill_trapping_insns() 回调，并且整个物理内存映射在直接映射中。
|
||||
具体改动
|
||||
即使系统 overutilized, 也要继续通过 feec() 寻找能效最优的 CPU. 否则, 回退到调度器的默认性能和传播模式(performance and spread mode).
|
||||
当工作队列的工作人员醒来进行短暂的后台工作（如vmstat更新）时，系统可能会在短时间内过度使用。
|
||||
继续寻找节能的CPU将防止破坏任务的电源包装。
|
||||
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user