- 博客(1039)
- 收藏
- 关注
RSS订阅转载 LWN：unstable pages 和 direct I/O 的碰撞！
2025年5月，Qu Wenruo 发布了一个补丁（patch），描述了当用户空间（user space）对启用校验和的Btrfs文件系统执行直接I/O，然后在I/O进行中修改其缓冲区时出现的问题。在这些情况下，对I/O中的页进行一次时机不当的更改，可能导致I/O错误（I/O errors）或数据损坏（data corruption）。如前所述，稳定页不适用于直接 I/O，因此，在底层块设备需要稳定页的情况下，Hellwig 的补丁会导致 XFS 回退到缓冲 I/O，即使已经请求了直接 I/O。
2025-11-24 13:28:21
1
转载 LWN：优化小文件反复读取性能的艰难之路！
Hugh Dickins 表达了同样的观点，但 Torvalds 表示，页缓存的其他部分会做“*更*可怕的事情”，而且将已知工作负载的性能提高三倍不一定是“小众”的。正如 Shutsemau（也被称为 Kirill Shutemov）在这个相对较短的补丁的更新日志（changelog）中解释的，执行文件读取的一个步骤是找到页缓存（page cache）中相关的 folio（页帧），并获取该 folio 的引用，以确保在数据复制回用户空间（user space）时其保持稳定。否则内核将回退到较慢的路径。
2025-11-19 13:24:25
30
转载 LWN：Mergiraf: 语法感知加持git合并！
这些事实被标记为是来自合并的基础版本（base revision）、左侧版本（left revision）还是右侧版本（right revision）（即最近的共同祖先、被合并到的提交和正在合并的提交）。无论哪种方式，合并后的程序行为都相同。另一方面，这并不是在 C 语言中解决同等合并冲突的正确方法，因为在 C 语言中，结构体成员的顺序会影响程序的正确性。但很少有人喜欢遇到合并冲突，而那些能够智能地解决它们——尤其是那些对人类来说显而易见，因而处理起来是浪费时间的冲突——的工具，是一个很有吸引力的前景。
2025-11-18 13:37:05
25
转载 LWN：用 Rust 实现 DebugFS！
因此，如果有人试图利用他的技巧创建一个指向存在的类型但无法构造该类型的值的指针，他们就可能破坏 Rust 的类型系统——这就是为什么辅助函数是 `unsafe` 的原因。Gary Guo 指出了 Maurer 编写的（unsafe）代码的一个潜在问题，该代码将函数类型转换回实际函数指针：虽然它对于函数类型是正确的，但尝试将其用于其他零大小类型可能会导致未定义行为（undefined behavior），因为它没有确保检查类型的内部不变量（internal invariants）。对这个解释的反应褒贬不一。
2025-11-03 13:31:58
144
转载 LWN：LLM 用在 patch review 上！
然而，Bird 说，应该期望提交者运行这些工具。Sasha Levin 称其为 "一个非常值得讨论的话题"，并表示，在 之前关于内核开发者使用 LLM 的讨论 中，对 LLM 提出的担忧盖过了任何寻找其潜在有用之处的尝试。Mason 的重点是 LLMs 如何通过在错误到达邮件列表之前将其捕获，并帮助贡献者提高提交内容的质量，从而减轻内核维护者的负担。为此，他整理了一组 提示词，这些提示词能够生成维护者所习惯的评审格式：“这些评审旨在看起来像 lkml 上的邮件，即使它们错得离谱，也确实达到了这个目的。
2025-10-30 13:24:50
246
转载 LWN：中断感知自旋锁的新API！
C 语言中现有的 irq-safe 自旋锁使用 `spin_lock_irq()`/`spin_unlock_irq()` 或 `spin_lock_irqsave()`/`spin_lock_irqrestore()`，具体取决于代码是否期望在中断启用（interrupt-enabled）的上下文中运行。冯伯群提出的方法很好地使 Rust 代码能够与中断感知自旋锁交互，但它还能实现另一个小的 API 更改：Rust 可以拥有一个单独的守卫类型，用于在非自旋锁原因下启用和禁用（per-CPU）中断。
2025-10-28 13:33:14
286
转载 LWN：内核开发即将支持哪些 Rust 语言特性！
由于 Rust for Linux 开发者希望使用自定义智能指针来处理不可信数据（untrusted data）、引用计数（reference counting）、外部锁（external locking）以及相关的内核复杂性，因此他们将受益于一个通用的语言特性，该特性允许所有指针类型使用相同语法进行字段投影。内有效的指针类型，投影一个字段会得到一个包裹了该结构体字段的（可能不同的）输出指针类型，且在相同的生命周期内有效。在 Rust 中，类型上的方法可以将类型本身的实例作为第一个参数，也可以是其引用。
2025-10-20 13:29:26
474
转载 LWN：关于 link tag 的规则！
仓库中的提交（commits）通常是（有时是漫长的）讨论的最终结果；多年来，许多维护者一直遵循一个惯例，即在提交中应用一个 Link 标签，指向该变更在邮件列表上的发布。核心问题始终未变：他不喜欢当他循着 Link 标签中的 URL，希望了解更多有关该变更的信息时，却只发现变更日志（changelog）中已有的相同信息。（值得注意的是，Gleixner 建议的另一部分——即每当补丁系列（patch series）更新时都包含一个指向之前发布的链接——尚未被广泛采纳，尽管许多开发人员确实包含了这些链接。
2025-09-30 13:30:00
866
转载 LWN：建立健康的内核子系统社区！
对于经验丰富的开发者，吹毛求疵或许有道理，但对于新来者，目标应该是给他们“那种‘是的，我的第一个补丁已经合并到主线（mainline）了’的微小鼓舞；你想要让他们上钩”。他澄清说，如果一个补丁在逻辑（logic）或实现（implementation）上有实际问题，他会要求修改，但对于简单的拼写错误（typo）之类的修复，最好直接处理。他知道其他维护者（maintainer）的做法不同，但在他看来，这样做可以节省维护者的时间，避免上下文切换（context switch）并再次（甚至可能多次）进行评审。
2025-09-26 13:32:25
983
转载 LWN：kernel 的新工具 wprobes, KStackWatch, KFuzzTest！
local_var_offset 和 local_var_len 参数指示了要监控的栈上特定变量的位置和大小，表示为从进入函数时栈指针（stack pointer）的偏移量。然而，该数据的格式并不简单。这项功能在内核环境中可能特别有用，因为内核中同时发生着许多事情，而问题的根源可能存在于一个庞大而复杂的系统中的任何位置。然而，这种测试都是从用户空间运行的，因此它能锻炼的代码受限于内核的用户空间 API。内核所拥有的功能是 kprobe（内核探测点），它允许在运行中的内核中（几乎）任何位置放置调试代码。
2025-09-25 13:37:48
1014
转载 LWN：内核有多少种配置？
例如，可以使用 Z3 的 Python 绑定来加载 klocalizer 的输出，并探索选项之间的相互关系。如果配置选项是独立的，那么理论上只需测试一个所有功能都启用的内核和一个所有功能都禁用的内核就足够了。请注意，这个结果仍然是对数尺度的，所以这个值是由不同选项之间的依赖关系所排除的内核配置方式数量的对数。面对如此多的配置选项，即使要弄清楚哪些选项是多余的、未使用的，或者可以通过简化来处理的，也可能很困难。，但在本例中，内核配置中的约束足够简单，一个名为 ganak 的精确计数器能够准确地解决这个问题。
2025-09-24 13:35:36
1003
转载 LWN：可以处理复杂死锁检测的依赖跟踪机制！
每当一个线程获取一个锁时，lockdep 都会记住这次获取，以及当时的上下文——特别是，当时持有的任何其他锁。像 DEPT 这样的工具可能很有用且受欢迎，但它需要以一系列较小的更改形式进入主线（mainline），逐步将 lockdep 演进为具有 DEPT 依赖观念的工具，从而让内核在每一步都变得更好。在上面的例子中，A 的释放取决于事件 B 的发生，而事件 B 又取决于 C 的释放，C 的释放本身又取决于 A 的释放。他总结道，在死锁场景比 lockdep 能处理的更复杂的情况下，应该使用 DEPT。
2025-09-22 13:05:42
1044
转载 LWN：用 Rust 在内核跟踪数据可信度！
Lossin 建议采用这种形式的 API，因为将 `&mut Untrusted<[u8]>`（一个对不可信字节切片的可变引用）转换为 `&mut [Untrusted<u8>]`（一个对单独不可信字节切片的可变引用）可以自动完成——由于 `Untrusted` 的 `DerefMut` 实现，编译器会在需要时插入转换——但反向转换则需要显式的函数调用。对于自定义类型 `T`，`Validate<S>` 的实现包含了将 `Untrusted<S>` 转换为普通 `T` 所需的逻辑。
2025-09-16 13:29:06
1099
转载 LWN：kernel 未来如何对待32-bit支持？
Bergmann 已发送补丁以移除对 32 位 CPU 上的 KVM (Kernel-based Virtual Machine) 支持，但仍有“一个 PowerPC 用户”，因此该支持目前将保留。然而，这样的系统极其罕见，对它们的支持很快就会被移除。不过，这些系统也有一些用例。对于 x86 支持，他查看了大量旧网页，列出了哪些系统存在，然后指出这些系统中的每一个都因其他原因而在当前内核中已经无法正常工作；鉴于 Bergmann 是内核架构支持的整体维护者，他经常被问及是否可以移除对 32 位系统的支持。
2025-09-15 13:30:03
1128
转载 LWN：极其小巧的Microdot web framework！
例如，他恒温器设备中的 ESP8266 拥有 64KB 的 RAM (随机存取存储器) 和高达 4MB 的 flash (闪存)。根据统计，Django 有 110,000 行，Flask 加上其核心 Werkzeug library (库) 有 15,500 行，FastAPI 加上 Starlette 有 14,900 行，Bottle 约有 3,000 行，而 Microdot 核心只有 765 行（“信不信由你”），在 MicroPython 上安装所有扩展后，总代码行数略低于 1,700 行。
2025-09-08 13:36:04
1265
转载 LWN：用 clone3() 控制影子堆栈！
影子栈 (shadow stack) 是一种控制流完整性 (control-flow-integrity) 功能，旨在防御通过操纵线程的调用栈 (call stack) 来进行的攻击。虽然调用栈上会压入相当多的信息——例如局部变量 (local variables) 和保存的寄存器 (saved registers)——但影子栈只保存返回地址，因此相同大小的影子栈很可能对线程来说过于庞大。每当一个新的线程产生时，内核都会根据其常规栈的大小，为其分配一个相同大小的影子栈，作为对正确大小的最佳猜测。
2025-09-04 13:25:52
1335
转载 LWN：6.17 合并窗口的后半部分！
网络*：Qualcomm IPQ5018 内部 PHY、Airoha AN7583 MDIO 总线控制器、Broadcom 50/100/200/400/800 千兆以太网卡、Microchip Azurite DPLL/PTP/SyncE 设备以及 Realtek 8851BU 和 8852BU USB 无线网络 (Wi-Fi 6) 适配器。供电设备 (PSE) 实现增加了对可配置预算评估策略的支持，这些策略“被 PSE 控制器用于在功率预算超出等情况下决定首先关闭哪些端口”。详情请参阅 此合并消息。
2025-08-26 13:19:46
1613
转载 LWN：讨论内核开发中使用 LLM 助手！
目前，关于基于大型语言模型（LLM）的工具如何融入内核开发社区，存在着许多持续的讨论。Levin 的 观点 是，内核目前的策略是“我们接受代理生成（agent generated）的贡献，除了对普通人类的要求外，没有任何其他要求”；因此，如果没有这样的策略（policy），我担心仅仅合并这些补丁本身就会传递出一个信息，即内核现在正式接受使用编程助手完成的贡献，并且这些助手会根据配置文件（configuration files）做正确的事情，而使用助手的开发者无需再操心其他事情，因为一切都已由配置涵盖。
2025-08-21 13:39:31
1645
转载 LWN：6.17 合并窗口第一部分！
file_operations 结构 (structure) 中长期存在的 mmap() 方法正逐渐被弃用，转而支持 mmap_prepare()，后者减少了出现错误 (bugs) 和安全问题 (security problems) 的机会。新的 Rust 抽象 (abstractions) 已添加到稳压器子系统 (regulator subsystem)、固件属性 (firmware properties)、I/O 资源 (I/O resources) 和 I/O 内存 (I/O memory) 中。
2025-08-18 13:14:51
1760
转载 LWN：更好地控制透明巨页的使用！
PR_SET_THP_DISABLE 的实现是强制性的；相反，Hildenbrand 的补丁为 PR_SET_THP_DISABLE 添加了一个新选项，名为 PR_THP_DISABLE_EXCEPT_ADVISED，它提供了新的语义。正如 David Hildenbrand 的这个补丁（Usama Arif 已将其作为 这个系列 的一部分）所描述的，人们可以考虑让 madvise() 覆盖 PR_SET_THP_DISABLE，但正如 Hildenbrand 所说，“这会大大改变现有文档中描述的语义”。
2025-08-14 13:31:20
1744
转载 LWN：Graphene OS——更安全的安卓版本！
其中一些改动，例如强化的 malloc() 库（hardened malloc() library）或额外控制流完整性（control-flow-integrity）功能的使用，对用户来说大都是不可见的（当然，除非它们导致应用崩溃，这显然是已知会发生的）。再加上有消息称 Google 的“Gemini”越来越觉得无论设备如何配置，它都有权访问设备所有者的数据，这促使我购买了一台 Pixel 9 设备，用于 GrapheneOS 的实验，以查看它是否能取代日常使用的原生 Android。
2025-08-13 12:52:34
2548
转载 LWN：介绍一下 niri 滚动平铺 Wayland 合成器！
新版本在他认为合适的时机发布。Niri 是一款相对较新的、基于 Rust 编写的 Wayland 合成器 (compositor)，它对 平铺窗口管理 (tiling window management) 采用了不同的方法：窗口以“无限”行的方式在屏幕上放置，可以扩展超出可见工作区的边界。根据 niri 项目的 README 文件，Molodetskikh 喜欢 PaperWM 的窗口管理模式，但他决定编写自己的合成器（compositor），以克服 PaperWM 在将工作区独立到单个显示器方面的限制。
2025-07-22 13:35:11
3582
转载 LWN：逐步统一kselftests和KUnit！
Weißschuh 的系列补丁继续单独构建这些测试，但生成的二进制文件被链接到新的 `kunit-uapi` 模块中，然后该模块在单独的 per-CPU 内核线程（kernel thread）中运行它们。虽然许多类型的内核测试只能在特定硬件存在的情况下进行，但内核的其他部分可以得到更广泛的测试。然而，随着时间的推移，内核已经获得了两个独立的测试框架以及随之而来的越来越多的自动化测试。相反，在该系列补丁结束时唯一启用的测试是一个简单的示例测试和一个验证 `/proc` 挂载的测试。
2025-07-21 13:15:35
2233
转载 LWN：kernel API 规范和验证
API 还有其他方面，例如 `/proc` 或 `/sys` 中的文件，由 perf-events 子系统 (perf-events subsystem) 或 io_uring 创建的内存映射区域，以及任何给定类型文件描述符可用的操作集。然而，总得有个开始。未来的计划包括与静态分析 (static analysis) 集成以验证 API 规范，与模糊测试工具 (fuzzing tools) 集成以进行更智能的测试，以及可在生产内核中启用的低开销运行时验证 (run-time validation)。
2025-07-17 14:12:52
2259
转载 LWN：Fedora i686 的命运得到缓刑！
新任 Fedora 项目负责人 Jef Spaleta 表示，他认为当前的提案是一种必要的激励，旨在让“适当的人制定出一个破坏性更小的可行计划”。在后续评论中，他说 Fedora 必须找到一种方法将 i686 工作“分离出来，让那些背负负担的人可以放下，而关心它的人则可以接手”。我只是想把它写下来。Steam 和 Wine 所需的软件包需要与 Fedora 保持同步，并且可能需要应用更改才能长期保持 32 位构建，这意味着版本会漂移，并且我们有发布损坏构建的风险，除非我们也能在出现不匹配时暂停/阻止构建。
2025-07-16 13:35:55
2126
转载 LWN：利用机器学习来更好地实现负载均衡！
它使用了一个相对简单的算法：系统中一半的 CPU 保留给延迟敏感的网络处理任务，而另一半则用于 CPU 密集型通用处理。为了特定用例，人们曾做出各种努力来编写 CFS 的替代品，其中值得注意的是 2009 年 Con Kolivas 提交的 BFS，以及 2016 年他提交的 MuQSS。调度器必须考虑任务的优先级、CPU 需求、其当前的虚拟运行时间，以及最近的 CPU 使用模式。当然，还有特定工作负载相关的因素。Huang 表示，所有这些的最终结果是，任何使用单一、固定算法的调度器都从根本上是失效的。
2025-07-15 13:06:59
2182
转载 LWN：配置透明巨页的一个新方法！
他提议的接口将是一个“结构体配置函数（struct-configured function）”，它接受一个描述所用应用程序编程接口（API）版本的新结构体，以及几种可能的操作之一。一个可选的 pidfd 可以将操作应用于一个单独的进程，并且一组布尔标志将配置该调用如何响应错误或请求范围中的空洞。尽管这些补丁集尚未公布，但邮件列表上的讨论清楚表明，设置进程特定 THP 策略的用例是存在的。Arif 认为Stoakes 的提议没有必要，并且会“引入大量代码来解决可以用非常非常简单的方式完成的事情”。
2025-07-14 13:31:29
1991
转载 LWN：如何在kernel里写Rust代码——第二部分！
在用户空间的 Rust 项目中，程序通常也会从 std（Rust 的标准库）中导入一些内容，但在内核中这不可行，因为内核需要对内存分配和其他标准库抽象掉的细节有更精确的控制。的形式书写，它适用于其所出现的定义内部。约定俗成是，对于返回值的宏使用圆括号，而对于调用以定义结构体的宏使用花括号（此处即是这种情况），但这并非强制要求。在驱动程序的 C 版本中，下一步是定义一些常量，它们代表了该驱动程序支持的三种不同但相关的设备：AX88772A、AX88772C 和 AX88796B。每个板卡对应的类型（例如。
2025-07-11 12:54:34
1631
转载 LWN：用 LLM 帮助内核开发！
接着，他介绍了“嵌入”（embeddings）的概念，这是一种在 LLM 内部表示文本的方式。它的工作原理是为历史中的每个提交创建一个嵌入，然后查找与可能解决同一类问题的新提交之间的相似之处。然而，与内核中常见的那种状态机不同，LLM 执行状态转换的方式是概率性的，而非确定性的。因此，一个纯粹基于人类的流程会滞后，遗漏重要的漏洞，同时偶尔会标记出实际上不是漏洞的错误。他总结说，通过使用 LLM，内核社区现在拥有一个系统，可以利用多个模型，直接访问 Git 仓库，并利用历史数据来回答关于内核补丁的各种问题。
2025-07-10 13:31:15
1516
转载 LWN：Asterinas，兼容Linux的一个内核项目！
Asterinas 使用硬件隔离来允许运行任何编程语言编写的用户空间程序，旨在通用化，并提供 Linux 兼容的 ABI，而 RedLeaf 则是一个微内核，其设计目的/不/是使用硬件的隔离特性，并且该项目关注点不同。显然，对 Linux virtio 设备的支持已经存在，因此一个主要的障碍已经清除。另外两个是 OSTD（被描述为“一个 Rust OS 框架，旨在促进用 Rust 编写的操作系统内核的开发和创新”）和 OSDK（一个 Cargo 插件，用于辅助基于 OSTD 的内核的开发、构建和测试）。
2025-07-09 13:21:02
1696
转载 LWN：分布式备份存储文件系统：ngnfs！
客户端尝试以块遍历顺序获取块访问权限，但该顺序可能会改变，因此客户端的结构是使用尝试锁 (trylocks)，即尝试获取锁，如果无法获取则不阻塞。该文件系统是元数据密集型系统，归档代理主要对扩展属性 (xattrs) 进行元数据更改，这些属性描述了文件内容当前的存储位置，包括数据所在的存储层级以及在介质（例如磁带）上的位置等信息。Brown 说，这就是该文件系统的背景：“大量文件，主要进行元数据流转，但令人恼火的是，随着文件内容的流动，我们需要大量聚合带宽，这样就不是一个节点来完成所有这些工作了。
2025-07-08 13:32:56
1504
转载 LWN：libxml2 不再陪着玩安全漏洞披露游戏！
最初这可能算是一种增长黑客手段（growth hack），但现在这些公司赚取了数十亿美元的利润，却拒绝偿还他们的技术债务（technical debt），无论是通过切换到更好的解决方案、开发自己的，还是尝试改进 libxml2。总有一天，会有人来找你，说：“我来自苹果，我来自亚马逊，我来自 Google Project Zero，你需要放下手头的一切，因为你的项目是新的心脏滴血漏洞（Heartbleed）或 Log4j 漏洞（Log4j），世界正在崩塌。我越是思考，就越是意识到这是唯一的出路。
2025-07-07 13:22:46
1562
转载 LWN：kernel defconfig是为谁准备的？
内核的配置选项控制着内核如何构建的诸多方面。它 启用了许多内存管理选项（memory-management options），包括内存热插拔（memory hotplugging）、内核同页合并（kernel samepage merging，KSM）、透明大页（transparent huge pages）、userfaultfd 机制（userfaultfd）、内存控制组（memory control groups）以及 多代 LRU（multi-generational LRU）。
2025-07-04 17:59:08
1458
转载 LWN：如何在 kernel 里写 Rust 代码：第一部分！
尽管 GCC 上对 Rust 的支持正在迎头赶上，并且 `rustc_codegen_gcc` 代码生成后端现在能够编译内核的 Rust 组件，但 Rust for Linux 项目目前仅支持使用纯粹的 `rustc` 进行构建。Rust 开发者可能还应该安装 Clippy（Rust 的代码 Lint 工具），rustdoc（Rust 的文档构建工具）和 rust-analyzer（Rust 的 语言服务器），但这些并非严格必需。构建和测试 Rust 代码是审查 Rust 代码的必要条件，但并非充分条件。
2025-07-03 13:34:46
1559
转载 LWN：推动 Lustre 文件系统进入上游！
作为一名 VFS 维护者，他不想成为那个做决定的人，但合并一个新的文件系统“会给整个社区带来负担”，因此这应该是一个共同的决定。客户端“每月有几百个补丁，服务器的补丁量是客户端的三到四倍”，这使得跟上内核的步伐变得更加困难。Layton 说：“小步前进是好的”，不过 Day 指出，如果没有内核中的服务器代码，测试 Lustre 会更困难。这会影响 ext4 的开发，但其他更改，例如重写 jbd2 日志层使其不再需要 buffer heads 的计划，也可能因为包含 Lustre 服务器而变得复杂，他说。
2025-07-02 13:28:37
1380
转载 LWN：分层固定带宽服务调度器！
相反，如果没有可运行的任务，截止期限服务器就会放弃 CPU，使其可供任何可能正在争夺它的实时任务使用。当截止期限服务器运行时，它将以通常的方式调度该组内的任务，确保整个组获得分配给它的资源，即使系统中其他地方有更高优先级的实时任务试图运行。有一个 CBS 调度器，即截止期限调度器（deadline scheduler）（详情请参阅备受怀念的 Daniel Bristot de Oliveira 撰写的 这篇文章），但该调度器并非分层的，并且要求实时任务是专门为其编写的。（所需的 CPU 时间）；
2025-07-01 13:08:40
1324
转载 LWN：文件系统回写并行化！
在一些简单的测试中，当禁用 XFS 的大页时，他在内核回写线程饱和之前能达到大约每秒 800MB 的速度。现有单线程回写所遇到的一些性能问题，在去年峰会的一次会议上曾被提及，当时讨论了并行回写的想法。他认为，对于多线程回写的第一个版本，保持单个 inode 列表将是合理的。通过远程连接，Jan Kara 表示他听到的情况是，大多数人的兴趣在于低层并行，这将并行化单个 inode 的回写。在该层，不同类型的文件系统操作，例如 XFS 的块分配与纯覆盖写入，可以由独立的工作队列（workqueue）处理。
2025-06-26 13:10:10
1233
转载 LWN：用 Smatch 来发现 bug！
这类报告需要跨函数分析（cross-function analysis），以跟踪持有锁的嵌套调用（nested calls），但它也需要一些关于哪些函数获取或释放锁（acquire or release a lock）的起始知识。“而我就是编写它的人。他说，最常见的错误是在函数的错误路径（error path）中未能释放锁。他说，锁检查的重新实现（reimplementation）为如何编写模块化 Smatch 检查（modular Smatch checks）提供了一个蓝图（blueprint）。
2025-06-25 14:17:11
1219
转载 LWN：6.16合并窗口的后半部分！
一系列内存管理（memory-management）变更包括更多的 folio 转换、用于核心内存管理操作（core memory-management operations）的Rust 抽象、对内存整理（memory compaction）的更好支持，以及移除。的改进，包括支持在 BPF 中计算系统调用统计信息（system call statistics）、更好地解密 Rust 符号、更精细的选项用于收集内存统计信息、一个用于故意引入锁争用（lock contention）的标志等等。
2025-06-24 13:20:33
1214
转载 LWN：移除block层的 bounce buffer！
在 90 年代，在一个这样的系统中拥有超过 1GB 的内存被认为是令人震惊的。如果一个 I/O 请求涉及高内存中的缓冲区，而负责处理该请求的驱动无法处理高内存，数据就会被复制（即“回弹”）到一个低内存缓冲区。bounce buffer 还会增加操作使用的内存，如果系统内存压力大，并且正在写入数据以便回收和重用其占用的页面，这可能会带来特别的问题。这套补丁集包含在 6.16 版本的首批合入中，它从内核中移除了近 300 行代码，也许更重要的是，它从块 I/O 路径中剔除了一个令人烦恼的特殊情况。
2025-06-18 13:25:31
1150
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人