description/open_source: update phoronix vs LWN to date 20240915

This commit is contained in:
Cheng Jian
2024-10-14 09:56:33 +08:00
parent cbdd04c553
commit 64571fc2da
12 changed files with 180 additions and 27 deletions
+2 -2
View File
@@ -243,7 +243,7 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
| 4 | [BertViz](https://github.com/jessevig/bertviz) | Jessevig | 使用交互式的方式, 可视化 Transformer 语言模型 (如 BERT, GPT2) 的注意力机制, 可在 Jupyter 或 Colab 中运行, 通过简单的 Python API 支持大多数 Hugging Face 预训练模型 (如 BERT, GPT2, T5 等), BertViz 扩展了 Llion Jones 的 Tensor2Tensor 可视化工具, 提供了头视图, 模型视图, 神经元视图等多个不同的可视化方式, 每个视图都提供了一个独特的视角来了解注意力机制. 参见 [2019/04/11, Human-Computer Interaction (cs.HC), Visualizing Attention in Transformer-Based Language Representation Models](https://arxiv.org/abs/1904.02679). |
| 5 | [LLM Visualization](https://github.com/bbycroft/llm-viz | bbycroft | 将 Transformer 原理的详细细节通过交互可视化的方式一步步显示出来, 详细的展示了每一步的数学原理, 模型的网格结构, 参数构造的运行过程, 可以精确到每一步观察大模型运行的运算以及数据的变化. 作者的 [仓库 bbycroft/llm-viz](https://github.com/bbycroft/llm-viz) 以及 [在线演示地址 bbycroft.net/llm](https://bbycroft.net/llm), [@HansChanX](https://x.com/HansChanX) LLM 可视化演的中文翻译版本: [仓库 czhixin/llm-viz-cn](https://github.com/czhixin/llm-viz-cn) 以及 [](https://llm-viz-cn.iiiai.com/llm). 其他 [Vaaaas/llm-viz-CN](https://github.com/Vaaaas/llm-viz-CN), 知乎报道 [矩阵模拟!Transformer 大模型 3D 可视化,GPT-3、Nano-GPT 每一层清晰可见](https://zhuanlan.zhihu.com/p/670287271) |
| 6 | [Machine-Learning-Tokyo/Interactive_Tools](https://github.com/Machine-Learning-Tokyo/Interactive_Tools) | 这个项目收集了各种用于机器学习、深度学习和数学的交互式工具. |
| 7 | [hahnyuan/LLM-Viewer](https://github.com/hahnyuan/LLM-Viewer) | 一个可视化语言与学习模型 LLMs 并分析在不同硬件平台上性能的工具. 可以进行网络级分析, 考虑峰值内存消耗和总推理时间成本等因素. 使用 LLM-Viewer, 可以获取 LLM 推理和性能优化的宝贵见解. 可以在 Web 浏览器或者命令行(CLI) 工具中使用. 在线体验地址 [LLM-Viewer Web](http://llm-viewer.com). 参见论文 [LLM Inference Unveiled: Survey and Roofline Model Insights](https://arxiv.org/abs/2402.16363). |
# 5 基础理论
-------
@@ -281,7 +281,7 @@ MoE(Mixed Expert Models), 即混合专家模型, 首次在 1991 年的论文 [Ad
| 时间 | 分类 | Survey | 作者 | GitHub | 描述 |
|:---:|:----:|:------:|:---:|:------:|:----:|
| 2024/03/01 | 综述 | [NiuTrans/ABigSurveyOfLLMs](https://github.com/NiuTrans/ABigSurveyOfLLMs) | [NiuTrans](https://github.com/NiuTrans/ABigSurveyOfLLMs) | [NiuTrans](https://github.com/NiuTrans/ABigSurveyOfLLMs) | 一个关于大语言模型的综合性调研集合, 包含 150 多篇关于 LLM 的调研论文. 这些调研涵盖了 LLM 的各个方面, 包含通用调研, Transformer, 对齐, 提示学习, 上下文学习, 推理链, 提示工程, 数据, 评估, 社会问题, 安全性, 幻觉, 属性, 高效 LLM, 学习方法, 多模态 LLM, 基于知识的 LLM, 检索增强型 LLM, 知识编辑, LLM 扩展, LLM 与工具, LLM 与交互, 长序列 LLM, 以及 LLM 在教育, 法律, 医疗, 游戏, NLP 任务, 软件工程, 推荐系统, 图谱等领域的应用. |
| 2021/09/23 | 综述 | [metame-ai/awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | [metame-ai](https://github.com/metame-ai/awesome-llm-plaza) | [awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | NA |
| 2024/09/23 | 综述 | [metame-ai/awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | [metame-ai](https://github.com/metame-ai/awesome-llm-plaza) | [awesome-llm-plaza](https://github.com/metame-ai/awesome-llm-plaza) | NA |
| 2024/01/16 | 多模态 | [A Survey of Resource-efficient LLM and Multimodal Foundation Models](https://arxiv.org/abs/2401.08092) | Mengwei Xu | [UbiquitousLearning](https://github.com/UbiquitousLearning/Efficient_Foundation_Model_Survey) | 一篇关于资源高效的大模型和多模态基础模型的综述论文. 论文涵盖了算法和系统两个方面的创新, 包括了高校的模型架构, 训练算法, 推理算法和模型压缩等内容. |
| 2024/04/18 | 效率提升 | [The Efficiency Spectrum of Large Language Models: An Algorithmic Survey](https://arxiv.org/abs/2312.00678) | Tianyu Ding | [tding1](https://github.com/tding1/Efficient-LLM-Survey) | 一篇关于提供大语言模型效率的综合性调查论文, 全面回顾了旨在提高 LLM 效率的算法, 涵盖了扩展定律, 数据利用, 架构创新, 训练和调优策略以及推理计划等. |
| 2024/05/23 | LLMs | [Efficient Large Language Models: A Survey](https://arxiv.org/abs/2312.03863) | Zhongwei Wan | [AIoT-MLSys-Lab](https://github.com/AIoT-MLSys-Lab/Efficient-LLMs-Survey) | 本文对高效 LLMs 研究的发展进行了系统而全面的回顾, 并将文献整理成由三个主要类别组成的分类法, 从模型中心、数据中心和框架中心的角度涵盖了不同但相互关联的高效 LLMs 主题, 并且从以模型为中心和以数据为中心的角度, 回顾了 LLMs 的算法层面和系统层面的高效技术. 详细介绍了每个分类下的具体技术, 如: 量化, 剪枝, 知识蒸馏, 数据选择, 提示工程等<br>1. [知乎--黄浴--高效大语言模型:综述](https://zhuanlan.zhihu.com/p/671710012)<br>2. [知乎--磐石--大模型高效推理 I 推理技术框架总结](https://zhuanlan.zhihu.com/p/696850285)<br>3. [知乎--享享学AI--大模型LLM微调技术方法汇总!](https://zhuanlan.zhihu.com/p/673675939) |
File diff suppressed because one or more lines are too long
+2
View File
@@ -625,6 +625,8 @@ Wasmtime 完全开源, 使用 Rust 编程语言, 是的, 并且符合 WASI 标
[WASM 原生时代已经到来 | 解读 WebAssembly 的 2022](https://csdnnews.blog.csdn.net/article/details/128739217)
[Wasmer 4.3 Released: WebAssembly Runtime 25% Faster On Cold Startups](https://www.phoronix.com/news/Wasmer-4.3-Released)
[Wasmer 4.4 Released To Continue Pushing Universal Apps With WebAssembly](https://www.phoronix.com/news/Wasmer-4.4-Released)
# 10 云原生
-------
File diff suppressed because one or more lines are too long
@@ -444,4 +444,5 @@ kpatch 的实现一直是根据内核的进展而演进的, 对 JUMP_LABEL 的
| 2016/02/10 | Li Bin <huawei.libin@huawei.com> | [livepatch: patch creation tooling proposal](https://lore.kernel.org/all/cover.1477578530.git.jpoimboe@redhat.com) | Kpatch-Build | RFC ☐ 4.0-rc1 | [GitHub](https://github.com/dynup/kpatch) |
| 2016/02/10 | Jiri Slaby <jslaby@suse.cz> | [announcing LLpatch: arch-independent live-patch creation](https://lore.kernel.org/all/CABFpvm2o+d0e-dfmCx7H6=8i3QQS_xyGFt4i3zn8G=Myr_miag@mail.gmail.com) | Google 提供的新的用户空间实时补丁创建工具, LLpatch, 与 kpatch 构建并行, 但不需要它的特定于 arch 的代码来进行 ELF 分析和操作. 基于 LLVM-diff 可以访问比 kpatch 的 create-diff- -object 能够从 elf 级别的差异中推断出的更多信息. | RFC ☐ 5.14-rc1 | [GitHub](https://github.com/google/LLpatch) |
| 2023/03/06 | Joe Lawrence <joe.lawrence@redhat.com> | [livepatch: klp-convert tool](https://lore.kernel.org/all/20230306140824.3858543-1-joe.lawrence@redhat.com) | livepatches 可能会使用不包含在其自身作用域中的符号, 并且, 正因为如此, 最终可能会编译为只在模块加载期间解决的重定位. 然而, 当引用的符号没有导出时, 解决这个重定位问题需要关于保存符号的对象 (vmlinux 或模块) 及其在对象中的位置的信息, 因为一个对象可能包含多个具有相同名称的符号. 提供这些信息必须根据 `Documentation/livepatch/module-self-format.txt` 中指定的内容进行. 目前, 还没有一种简单的方法可以在最终的 livepatch elf 对象中嵌入所需的信息. klp-convert 以两种不同的形式解决了这个问题: 1. 依靠在内核编译期间构建的符号映射来自动推断重定位目标符号, 并且, 当这种推断不可能时.<br>2. 通过使用 elf 对象中的注释将重定位相应地转换为规范, 使其能够由 livepatch 加载器处理. 鉴于以上所述, 添加对符号形式的符号映射的支持 `.klp` 文件; 添加 klp 转换工具; 将 klp 转换工具集成到 kbuild 中; 使 livepatch 模块在内核编译管道中可识别; 添加数据结构和宏, 使用户能够注释 livepatch 源代码; 使 modpost stage 与 livepatches 兼容; 参见 [Understand and review klp-convert patchset](https://hackweek.opensuse.org/22/projects/understand-and-review-klp-convert-patchset), [klp-convert and livepatch relocations, LPC-2019](https://lpc.events/event/4/contributions/507/attachments/316/533/LPC2019.pdf). | v7 ☐☑✓ | [LORE v7,0/10](https://lore.kernel.org/all/20230306140824.3858543-1-joe.lawrence@redhat.com), [SUSE/klp-convert](https://github.com/SUSE/klp-convert), [joe-lawrence/linux](https://github.com/joe-lawrence/linux/tree/klp-convert-v5) |
| 2024/09/02 | Josh Poimboeuf <jpoimboe@kernel.org> | [objtool, livepatch: Livepatch module generation](https://lore.kernel.org/all/cover.1725334260.git.jpoimboe@kernel.org) | 引入一种新的构建 Livepatch 模块的工具: klp-build. 使用一个新的 objtool klp 子命令, 通过源代码补丁作为输入来生成 Livepatch 模块. 与现有的 kpatch-build 相比<br>klp-build<br>1. 设计更简单, 代码量减少了约 3000 行, 利用 objtool 的控制流图(CFG)功能来创建用于检测函数变化的校验和, 解决了__LINE__偏移变化的问题, 这得益于 adjust-patch-lines 脚本.<br>2. 利用现有工具: 通过使用现有的 objtool 功能, klp-build 能够检测函数变化, 从而简化了 Livepatch 模块的生成过程.<br>3. klp-build 能够运行在 vmlinux.o 上, 与 IBT 和 LTO 等后期链接功能兼容.使用方法: `scripts/livepatch/klp-build /path/to/my.patch`, 如果成功, 将在当前目录下创建补丁模块(livepatch.ko). | v1 ☐☑✓ | [LORE v1,0/31](https://lore.kernel.org/all/cover.1725334260.git.jpoimboe@kernel.org) |
+5 -1
View File
@@ -296,6 +296,8 @@ percpu rw 信号量是一种新的读写信号量设计, 针对读取锁定进
[Recent RCU changes](https://lwn.net/Articles/894379)
[The RCU API, 2024 edition](https://lwn.net/Articles/988638)
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2019/06/01 | "Joel Fernandes (Google)" <joel@joelfernandes.org> | [Harden list_for_each_entry_rcu() and family](https://lore.kernel.org/patchwork/cover/1082845) | 本系列增加了一个新的内部函数rcu_read_lock_any_held(), 该函数在调用这些宏时检查reader节是否处于活动状态. 如果不存在reader section, 那么list_for_each_entry_rcu()的可选第四个参数可以是一个被计算的lockdep表达式(类似于rcu_dereference_check()的工作方式). . | RFC ☑ 5.4-rc1 | [PatchWork RFC,0/6](https://lore.kernel.org/patchwork/cover/1082845) |
@@ -473,7 +475,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://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com) | Proxy Execution 是一种通用的优先级继承机制的实现方法, 用于解决优先级反转问题和其他类似的问题. 这些预备补丁的目的是为后续更复杂的 Proxy Execution 相关补丁打下基础.<br>在发送第 7 版 Proxy Execution 补丁集时, John Stultz 收到了反馈, 指出补丁集变得过于庞大难以审查. 因此, 根据 Qais Yousef 的建议, 他决定将补丁集分为两部分:一部分是预备性的更改, 另一部分是更复杂的功能实现. | v10 ☐☑✓ | [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) |
| 2024/05/06 | John Stultz <jstultz@google.com> | [Preparatory changes for Proxy Execution](https://lore.kernel.org/all/20240507045450.895430-1-jstultz@google.com) | Proxy Execution 是一种通用的优先级继承机制的实现方法, 用于解决优先级反转问题和其他类似的问题. 这些预备补丁的目的是为后续更复杂的 Proxy Execution 相关补丁打下基础.<br>在发送第 7 版 Proxy Execution 补丁集时, John Stultz 收到了反馈, 指出补丁集变得过于庞大难以审查. 因此, 根据 Qais Yousef 的建议, 他决定将补丁集分为两部分:一部分是预备性的更改, 另一部分是更复杂的功能实现. | v10 ☐☑✓ | [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) |
| 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_[startfinish]_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) |
@@ -506,6 +508,8 @@ Paul McKenney's parallel programming book, [LWN](https://lwn.net/Articles/421425
| [taskflow/taskflow](https://github.com/taskflow/taskflow) | Function Flow 并行化业界标杆, 犹他大学开发, 支持异构. [官网](https://taskflow.github.io). 论文<br>1. [Taskflow: A Lightweight Parallel and Heterogeneous Task Graph Computing System, TPDS 2021](https://taskflow.github.io/papers/tpds21-taskflow.pdf)<br>2. [Late Breaking Results: Efficient Timing Propagation with Simultaneous Structural and Pipeline Parallelisms, DAC 2022](https://tsung-wei-huang.github.io/papers/dac2022.pdf)<br>3. [Pipeflow: An Efficient Task-Parallel Pipeline Programming Framework using Modern C++, HPDC 2022](https://arxiv.org/abs/2202.00717)<br>4. [From RTL to CUDA: A GPU Acceleration Flow for RTL Simulation with Batch Stimulus, ICPP 2022](https://icpp22.gitlabpages.inria.fr/prog/) |
| [ChunelFeng/CGraph](https://github.com/ChunelFeng/CGraph) | ChunelFeng 的图化调度并行框架, 轻量, 快捷, 暂不支持异构 |
| [AthrunArthur/functionflow](https://github.com/AthrunArthur/functionflow) | 基于 C++11 的 FunctionFlow 并行编程库. |
| [symphony09/ograph](https://github.com/symphony09/ograph) | OGraph 是一个用 Go 实现的图流程执行框架. 可以通过构建Pipeline(流水线), 来控制依赖元素依次顺序执行、非依赖元素并发执行的调度功能. 此外, OGraph 还提供了丰富的重试, 超时限制. 执行追踪等开箱即用的特征. OGraph 受启发于另一个 C++项目 CGraph. 但 OGraph 并不等于 Go 版本的 CGraph. 和 CGraph 一样, OGraph 也提供基本的构图和调度执行能力, 但有以下几点关键不同:<br>1. 用 Go 实现, 使用协程而非线程进行调度, 更轻量灵活<br>2. 支持通过 Wrapper 来自定义循环、执行条件判断、错误处理等逻辑, 并可以随意组合<br>3. 支持导出图结构, 再在别处导入执行<br>4. 灵活的虚节点设置, 用以简化依赖关系, 以及延迟到运行时决定实际执行的节点. 实现多态. |
| [google-ai-edge/mediapipe](https://github.com/google-ai-edge/mediapipe) |
### 12.2.2 WorkQueue
@@ -810,11 +810,10 @@ github 地址: [Mitosis Project](https://github.com/mitosis-project), [linux 内
| 2021 | [Fast Local Page-Tables for Virtualized NUMA Servers with vMitosis; April, 2021; asplos21_vmitosis.pdf](https://research.vmware.com/files/attachments/0/0/0/0/1/3/8/asplos21_vmitosis.pdf)<br>[Fast Local Page-Tables for Virtualized NUMA Servers with vMitosis; April, 2021; vmitosis_ext_abstract.pdf](https://research.vmware.com/files/attachments/0/0/0/0/1/3/1/vmitosis_ext_abstract.pdf) |
## 1.x 其他页面页表相关
-------
【】()
| 时间 | 作者 | 特性 | 描述 | 是否合入主线 | 链接 |
|:----:|:----:|:---:|:----:|:---------:|:----:|
@@ -5674,8 +5673,10 @@ mcpage 有成本. 除了 THP 没有带来 TLB 的好处之外, 与 4K 基本页
|:---:|:----:|:---:|:----:|:---------:|:----:|
| 2024/03/11 | Maíra Canal <mcanal@igalia.com> | [drm/v3d: Enable Super Pages](https://lore.kernel.org/all/20240311100959.205545-1-mcanal@igalia.com) | [Raspberry Pi V3D Graphics Driver Preps For Super Pages To Boost Performance](https://www.phoronix.com/news/Raspberry-Pi-V3D-Super-Pages) | v3 ☐☑✓ | [LORE v3,0/5](https://lore.kernel.org/all/20240311100959.205545-1-mcanal@igalia.com) |
## 7.5 PAGE_SIZE
-------
[AmpereOne Performance On Linux 6.11 Kernel, 4K vs. 64K Page Size Comparison](https://www.phoronix.com/review/ampereone-64k-linux611)
# 8 进程虚拟地址空间(VMA)
-------
@@ -7273,6 +7274,7 @@ KFENCE 的灵感来自于 [GWP-ASan](http://llvm.org/docs/GwpAsan.html), 这是
|:----:|:----:|:---:|:----:|:---------:|:----:|
| 2021/08/05 | Mel Gorman <mgorman@techsingularity.net> | [Protect vmstats on PREEMPT_RT](https://lore.kernel.org/patchwork/patch/1472709) | NA | v2 ☐ | [PatchWork 0/1,v2](https://patchwork.kernel.org/project/linux-mm/cover/20210723100034.13353-1-mgorman@techsingularity.net) |
| 2021/12/22 | Shakeel Butt <shakeelb@google.com> | [memcg: add per-memcg vmalloc stat](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e5aa1f4c2b489bc6f3ab5ca54747b18a847289d) | NA | v1 ☑✓ 5.17-rc1 | [PatchWork v1](https://patchwork.kernel.org/project/linux-mm/patch/20211221215336.1922823-1-shakeelb@google.com)<br>*-*-*-*-*-*-*-* <br>[PatchWork v2](https://patchwork.kernel.org/project/linux-mm/patch/20211222052457.1960701-1-shakeelb@google.com) |
| 2024/07/30 | Pasha Tatashin <pasha.tatashin@soleen.com> | [Kernel stack usage histogram](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?id=fbe76a6557a83af5ef3819fd7b7ffd0a5d3b4e51) | 这个补丁集的目标是为 Linux 内核提供一个内核栈使用情况的直方图统计. 参见 [phoronix, 2024/09/24, Linux 6.12 Adds A Kernel Stack Usage Histogram To Help With Optimizations](https://www.phoronix.com/news/Linux-Kernel-Stack-Histogram). | v5 ☐☑✓ v6.12-rc1 | [2024/05/30, LORE v3](https://lore.kernel.org/all/20240530170259.852088-1-pasha.tatashin@soleen.com)<br>*-*-*-*-*-*-*-* <br>[2024/07/18, LORE v4](https://lore.kernel.org/all/20240718202611.1695164-1-pasha.tatashin@soleen.com)<br>*-*-*-*-*-*-*-* <br>[2024/07/30, LORE v5,0/3](https://lore.kernel.org/all/20240730150158.832783-1-pasha.tatashin@soleen.com) |
### 13.4.6 meminfo
+1 -1
View File
@@ -111,7 +111,7 @@
| 6.8 | [The first half of the 6.8 merge window](https://lwn.net/Articles/957188), [The rest of the 6.8 merge window](https://lwn.net/Articles/958178) | NA | NA |
| 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/) | NA | NA |
| 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 |
年终盘点
File diff suppressed because one or more lines are too long
+35
View File
@@ -0,0 +1,35 @@
这个补丁是由 Athira Rajeev 提交的, 标题为 "[PATCH V8 00/15] Add data type profiling support for powerpc". 这个补丁集(总共包含15个补丁)的主要目的是为 PowerPC 架构添加数据类型剖析(data type profiling)的支持.
补丁集背景
在补丁集中提到, 之前由 Namhyung Kim 提交的一系列补丁已经为 perf 工具引入了数据类型剖析的基本支持. 这些补丁使 perf 能够关联性能监控单元(PMU)的样本到它们所引用的数据类型, 利用 DWARF 调试信息来实现这一点. 目前, 这种支持已经在 x86 架构上可用, 可以通过 perf report 或 perf annotate 命令来查看数据类型信息.
补丁集内容
Athira Rajeev 的补丁集旨在为 PowerPC 架构添加类似的支持. 以下是该补丁集的主要更改点:
PowerPC 指令表更新: 添加了一个 PowerPC 指令助记符表, 用于将负载/存储指令与移动操作关联起来, 从而识别指令是否涉及内存访问.
获取寄存器编号和偏移量: 为了从给定的指令中获取寄存器编号和访问偏移量, 代码使用了 struct arch 中的 objump 字段. 为 PowerPC 添加了相应的条目.
获取寄存器编号函数: 实现了一个 get_arch_regnum 函数, 可以从寄存器名称字符串中返回寄存器编号.
解析原始指令
为了更准确地解析 PowerPC 指令, 补丁集采取了以下步骤:
使用原始指令: 补丁集支持直接使用原始指令而非解析后的指令名称. 这样可以通过宏来提取指令的操作码和寄存器字段.
示例: 例如, 使用 --show-raw-insn 选项时, objdump 会给出原始指令的十六进制表示, 如 "38 01 81 e8", 这对应于 "ld r4,312(r1)" 指令.
避免重复使用 objdump: 补丁集避免了重复使用 objdump 来读取原始指令, 而是直接从动态共享对象 (DSO) 中读取二进制代码.
具体补丁概述
Patch 4: 添加了支持捕捉和解析 PowerPC 原始指令的功能, 使用 dso__data_read_offset 实用程序.
Patch 5: 添加了 disasm_line__parse 函数来解析 PowerPC 的原始指令.
Patch 6: 更新了寄存器提取函数的参数, 以支持 PowerPC 上的原始指令.
Patch 7: 更新了 ins__find 函数来携带原始指令, 并为 PowerPC 添加了内存指令的解析回调.
Patch 8: 支持识别具有操作码 31 的 PowerPC 内存指令.
Patch 9: 添加更多指令来支持 PowerPC 上的指令跟踪.
Patch 10 和 11: 处理 PowerPC 上的指令跟踪.
Patch 12、13 和 14: 添加支持使用 libcapstone 库在 PowerPC 上解析指令.
Patch 15: 处理 perf annotate 的 insn-stat 选项.
测试结果
补丁集作者提供了测试结果, 其中展示了使用 perf annotate --data-type --insn-stat 命令的结果. 结果显示有大约 43.7% 的指令被正确解析, 而 56.3% 的指令未能成功解析. 作者指出还有大约 25% 的未知指令没有得到处理.
后续计划
作者提到这个补丁集还没有在 PowerPC32 架构上进行过测试. 下一步的增强计划包括处理剩余的未知指令, 并覆盖 PowerPC32 的变化, 具体取决于测试的结果. 此外, 关于全局寄存器的支持将会在解决完 Namhyung Kim 的评论后发布后续补丁.
总结
这个补丁集为 PowerPC 架构添加了数据类型剖析的支持, 并且引入了一系列技术来更准确地解析 PowerPC 指令, 以便更好地理解内存访问行为.
+26 -3
View File
@@ -661,6 +661,8 @@ cba6167f0adb
[A capability set for user namespaces](https://lwn.net/Articles/978846)
[A look inside the BPF verifier](https://lwn.net/Articles/982077)
[CRIB: checkpoint/restore in BPF](https://lwn.net/Articles/984313)
[Modernizing BPF for the next 10 years](https://lwn.net/Articles/977013/)
[HIVE: A Hardware-assisted Isolated Execution Environment for eBPF on AArch64](https://www.usenix.org/conference/usenixsecurity24/presentation/zhang-peihua)
[Direct-to-device networking](https://lwn.net/Articles/979549)
@@ -764,10 +766,31 @@ HUAWEI P10 Plus, Vicky, Android 7.0, EMUI 5.1
[New Power Sequencing Driver Subsystem Merged For Linux 6.11](https://www.phoronix.com/news/Linux-6.11-Power-Sequencing)
这个补丁系列是关于为 Rust 语言在 Linux 内核中添加通用的内核分配器(Allocator)支持. 以下是补丁系列的主要变更和目的:<br>1. 添加通用内核分配器支持: 目前主线上, Rust 在 Linux 内核中的内存分配仅限于 kmalloc. 这个补丁系列扩展了这一功能, 允许使用更多的内存分配器以及分配策略.<br>2. 自定义 Allocator trait: 为了避免向内核添加不稳定的 Rust 特性, 补丁系列没有扩展 Rust 的 alloc crate 中的 Allocator trait, 也没有扩展 BoxExt 和 VecExt 扩展. 而是引入了特定的 Allocator trait, 并由 Kmalloc、Vmalloc 和 KVmalloc 分配器实现, 这些分配器也是在这个系列中实现的. 为了使用新的分配器, 补丁系列添加了自定义的 `Box<T, A>``Vec<T, A>`` 类型(其中 A 是特定的分配器), 这些类型依赖于特定的分配器.<br>3. 移除对 alloc crate 的依赖: 通过这个系列的更改, 内核构建完全移除了对 Rust 的 alloc crate 的依赖.
定义内核专用类型: 定义了内核专用的 Box<T, A> 和 Vec<T, A> 类型, .
[Ghidra Software Reverse Engineering Framework](https://github.com/NationalSecurityAgency/ghidra)
| 2024/08/26 | NeilBrown <neilb@suse.de> | [block: change wait on bd_claiming to use a var_waitqueue, not a bit_waitqueue](https://lore.kernel.org/all/20240826063659.15327-2-neilb@suse.de) | TODO | v1 ☐☑✓ | [LORE v1,0/7](https://lore.kernel.org/all/20240826063659.15327-2-neilb@suse.de) |
https://lore.kernel.org/all/20240830130309.2141697-1-vincent.guittot@linaro.org/
[](https://www.phoronix.com/news/AMD-Linux-Hetero-Max-Detect)
| 编号 | 调度器 | 语言 | 用途 |
|:---:|:-----:|:----:|:---:|
| 1 | scx_lavd | 程序专注于交互性, 具体来说, 就是始终如一地从游戏中获得更高的帧速率. |
| 2 | scx_rustland | RUST | 将调度事件转发到用户空间, 在那里做出决策. 还包含 scx_rusty 用于复杂 CPU 拓扑上的负载平衡, 以及, 一个 scx_layered 分区计划程序. |
| 3 |
+8
View File
@@ -0,0 +1,8 @@
#!/bin/bash
sed -i 's//(/g' ./$1
sed -i 's//)/g' ./$1
sed -i 's//, /g' ./$1
sed -i 's/。/. /g' ./$1
sed -i 's//: /g' ./$1
sed -i 's//; /g' ./$1