- 博客(1016)
- 收藏
- 关注
转载 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
7
转载 LWN:Fedora i686 的命运得到缓刑!
新任 Fedora 项目负责人 Jef Spaleta 表示,他认为当前的提案是一种必要的激励,旨在让“适当的人制定出一个破坏性更小的可行计划”。在后续评论中,他说 Fedora 必须找到一种方法将 i686 工作“分离出来,让那些背负负担的人可以放下,而关心它的人则可以接手”。我只是想把它写下来。Steam 和 Wine 所需的软件包需要与 Fedora 保持同步,并且可能需要应用更改才能长期保持 32 位构建,这意味着版本会漂移,并且我们有发布损坏构建的风险,除非我们也能在出现不匹配时暂停/阻止构建。
2025-07-16 13:35:55
31
转载 LWN:利用机器学习来更好地实现负载均衡!
它使用了一个相对简单的算法:系统中一半的 CPU 保留给延迟敏感的网络处理任务,而另一半则用于 CPU 密集型通用处理。为了特定用例,人们曾做出各种努力来编写 CFS 的替代品,其中值得注意的是 2009 年 Con Kolivas 提交的 BFS,以及 2016 年他提交的 MuQSS。调度器必须考虑任务的优先级、CPU 需求、其当前的虚拟运行时间,以及最近的 CPU 使用模式。当然,还有特定工作负载相关的因素。Huang 表示,所有这些的最终结果是,任何使用单一、固定算法的调度器都从根本上是失效的。
2025-07-15 13:06:59
51
转载 LWN:配置透明巨页的一个新方法!
他提议的接口将是一个“结构体配置函数(struct-configured function)”,它接受一个描述所用应用程序编程接口(API)版本的新结构体,以及几种可能的操作之一。一个可选的 pidfd 可以将操作应用于一个单独的进程,并且一组布尔标志将配置该调用如何响应错误或请求范围中的空洞。尽管这些补丁集尚未公布,但邮件列表上的讨论清楚表明,设置进程特定 THP 策略的用例是存在的。Arif 认为Stoakes 的提议没有必要,并且会“引入大量代码来解决可以用非常非常简单的方式完成的事情”。
2025-07-14 13:31:29
76
转载 LWN:如何在kernel里写Rust代码——第二部分!
在用户空间的 Rust 项目中,程序通常也会从 std(Rust 的标准库)中导入一些内容,但在内核中这不可行,因为内核需要对内存分配和其他标准库抽象掉的细节有更精确的控制。的形式书写,它适用于其所出现的定义内部。约定俗成是,对于返回值的宏使用圆括号,而对于调用以定义结构体的宏使用花括号(此处即是这种情况),但这并非强制要求。在驱动程序的 C 版本中,下一步是定义一些常量,它们代表了该驱动程序支持的三种不同但相关的设备:AX88772A、AX88772C 和 AX88796B。每个板卡对应的类型(例如。
2025-07-11 12:54:34
126
转载 LWN:用 LLM 帮助内核开发!
接着,他介绍了“嵌入”(embeddings)的概念,这是一种在 LLM 内部表示文本的方式。它的工作原理是为历史中的每个提交创建一个嵌入,然后查找与可能解决同一类问题的新提交之间的相似之处。然而,与内核中常见的那种状态机不同,LLM 执行状态转换的方式是概率性的,而非确定性的。因此,一个纯粹基于人类的流程会滞后,遗漏重要的漏洞,同时偶尔会标记出实际上不是漏洞的错误。他总结说,通过使用 LLM,内核社区现在拥有一个系统,可以利用多个模型,直接访问 Git 仓库,并利用历史数据来回答关于内核补丁的各种问题。
2025-07-10 13:31:15
148
转载 LWN:Asterinas,兼容Linux的一个内核项目!
Asterinas 使用硬件隔离来允许运行任何编程语言编写的用户空间程序,旨在通用化,并提供 Linux 兼容的 ABI,而 RedLeaf 则是一个微内核,其设计目的/不/是使用硬件的隔离特性,并且该项目关注点不同。显然,对 Linux virtio 设备的支持已经存在,因此一个主要的障碍已经清除。另外两个是 OSTD(被描述为“一个 Rust OS 框架,旨在促进用 Rust 编写的操作系统内核的开发和创新”)和 OSDK(一个 Cargo 插件,用于辅助基于 OSTD 的内核的开发、构建和测试)。
2025-07-09 13:21:02
177
转载 LWN:分布式备份存储文件系统:ngnfs!
客户端尝试以块遍历顺序获取块访问权限,但该顺序可能会改变,因此客户端的结构是使用尝试锁 (trylocks),即尝试获取锁,如果无法获取则不阻塞。该文件系统是元数据密集型系统,归档代理主要对扩展属性 (xattrs) 进行元数据更改,这些属性描述了文件内容当前的存储位置,包括数据所在的存储层级以及在介质(例如磁带)上的位置等信息。Brown 说,这就是该文件系统的背景:“大量文件,主要进行元数据流转,但令人恼火的是,随着文件内容的流动,我们需要大量聚合带宽,这样就不是一个节点来完成所有这些工作了。
2025-07-08 13:32:56
193
转载 LWN:libxml2 不再陪着玩安全漏洞披露游戏!
最初这可能算是一种增长黑客手段(growth hack),但现在这些公司赚取了数十亿美元的利润,却拒绝偿还他们的技术债务(technical debt),无论是通过切换到更好的解决方案、开发自己的,还是尝试改进 libxml2。总有一天,会有人来找你,说:“我来自苹果,我来自亚马逊,我来自 Google Project Zero,你需要放下手头的一切,因为你的项目是新的心脏滴血漏洞(Heartbleed)或 Log4j 漏洞(Log4j),世界正在崩塌。我越是思考,就越是意识到这是唯一的出路。
2025-07-07 13:22:46
222
转载 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
260
转载 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
292
转载 LWN:推动 Lustre 文件系统进入上游!
作为一名 VFS 维护者,他不想成为那个做决定的人,但合并一个新的文件系统“会给整个社区带来负担”,因此这应该是一个共同的决定。客户端“每月有几百个补丁,服务器的补丁量是客户端的三到四倍”,这使得跟上内核的步伐变得更加困难。Layton 说:“小步前进是好的”,不过 Day 指出,如果没有内核中的服务器代码,测试 Lustre 会更困难。这会影响 ext4 的开发,但其他更改,例如重写 jbd2 日志层使其不再需要 buffer heads 的计划,也可能因为包含 Lustre 服务器而变得复杂,他说。
2025-07-02 13:28:37
307
转载 LWN:分层固定带宽服务调度器!
相反,如果没有可运行的任务,截止期限服务器就会放弃 CPU,使其可供任何可能正在争夺它的实时任务使用。当截止期限服务器运行时,它将以通常的方式调度该组内的任务,确保整个组获得分配给它的资源,即使系统中其他地方有更高优先级的实时任务试图运行。有一个 CBS 调度器,即截止期限调度器(deadline scheduler)(详情请参阅备受怀念的 Daniel Bristot de Oliveira 撰写的 这篇文章),但该调度器并非分层的,并且要求实时任务是专门为其编写的。(所需的 CPU 时间);
2025-07-01 13:08:40
324
转载 LWN:文件系统回写并行化!
在一些简单的测试中,当禁用 XFS 的大页时,他在内核回写线程饱和之前能达到大约每秒 800MB 的速度。现有单线程回写所遇到的一些性能问题,在去年峰会的一次会议上曾被提及,当时讨论了并行回写的想法。他认为,对于多线程回写的第一个版本,保持单个 inode 列表将是合理的。通过远程连接,Jan Kara 表示他听到的情况是,大多数人的兴趣在于低层并行,这将并行化单个 inode 的回写。在该层,不同类型的文件系统操作,例如 XFS 的块分配与纯覆盖写入,可以由独立的工作队列(workqueue)处理。
2025-06-26 13:10:10
427
转载 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
449
转载 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
491
转载 LWN:移除block层的 bounce buffer!
在 90 年代,在一个这样的系统中拥有超过 1GB 的内存被认为是令人震惊的。如果一个 I/O 请求涉及高内存中的缓冲区,而负责处理该请求的驱动无法处理高内存,数据就会被复制(即“回弹”)到一个低内存缓冲区。bounce buffer 还会增加操作使用的内存,如果系统内存压力大,并且正在写入数据以便回收和重用其占用的页面,这可能会带来特别的问题。这套补丁集包含在 6.16 版本的首批合入中,它从内核中移除了近 300 行代码,也许更重要的是,它从块 I/O 路径中剔除了一个令人烦恼的特殊情况。
2025-06-18 13:25:31
587
转载 LWN:6.16 合并窗口前半部分!
AMD ACP 7.x,Cirrus Logic CS35L63 放大器和 CS48L32 音频处理器,Everest Semiconductor ES8375s 和 ES8389s,Longsoon-1 AC'97 音频编解码器,NVIDIA Tegra264 SoC,Richtek ALC203 和 RT9123 编解码器,Rockchip SAI 控制器,Intel WCL,以及 DJM-V10 混音器。这使得可以更好地控制 futex 在内存中的位置,以便将它们放置在靠近使用它们的进程的地方。
2025-06-17 13:26:22
633
转载 LWN:关于更快进行网络传输的两个议题!
Borkmann 的想法是在物理网卡上预留一组队列,将这些队列绑定到 Cilium 的 Netkit (一个旨在帮助减少网络命名空间开销的内核驱动程序),并将这些队列专用于容器的网络命名空间。简而言之,发往虚拟机中运行的应用的网络数据包必须由物理硬件接收,由主机内核处理,转发到虚拟容器桥接网络 (virtual container bridge network),然后交给 QEMU 虚拟网络设备的主机端,传入虚拟机,最后由客户机内核处理。随后,Wang 提出了一些不同的、更具推测性的提升性能的想法。
2025-06-16 13:13:31
635
转载 LWN:OSPM 2025 报道——第三天!
很显然,这并非总是可取的,因此,当一个运行队列(run queue)的利用率超过 CPU 容量(capacity)的 80% 时,EAS 会自动停用,并回退到传统的容量感知负载均衡(load balancing)模式。因此,调度器会将捐赠者出队(dequeue),然后将其添加到其等待的锁的持有者任务关联的一个列表中。对我们所有人来说,应该清楚的是,仅依靠 Android 发布周期中的测试是不够的,并且存在将回归(regressions)引入主线(mainline)EAS/uclamp 代码的风险。
2025-06-13 14:16:56
718
转载 LWN:设备发起的 I/O
Bates 说,既然已经可以像从 PCIe设备进行DMA那样做,那么“具有足够智能、能够在设备上运行代码来生成NVMe-submission-queue(NVMe 提交队列) 条目并敲响门铃 (doorbells)”的accelerator(加速器) 或其他某种I/O device(I/O 设备) 就可以处理自己的 I/O——或者其他设备的 I/O。Bates 说,CXL也有类似的功能。Bates 说,这听起来是设备发起 I/O 的一个有前景的方向,他还有一个略有不同的主题,想在剩下的几分钟里讨论。
2025-06-12 13:25:45
731
转载 LWN:新的 DMA-mapping API!
DMA users 将不再需要使用 SG lists ,而是能够直接管理他们自己的 I/O virtual address (IOVA) space (I/O 虚拟地址,简称 IOVA),这由 I/O memory-management unit (IOMMU) (I/O 内存管理单元,简称 IOMMU) 提供。的,这很好,但使用 DMA 需要 scatter-gather (SG) lists (分散收集列表,简称 SG list),因此在这两种 formats (格式) 之间存在大量的转换。
2025-06-04 13:34:40
836
转载 LWN:作为内核开发者来尝试 Home Assistant:案例分析!
所以我无法测试这些集成。我能够以一种稍微简单的方式解决了这个问题(运行 Home Assistant 的机器有两个网络端口,所以我省去了中间的树莓派系统),从那以后,我便能完全访问太阳能系统的数据了。换句话说,我拥有的太阳能电池板生成的数据,由我拥有的监控系统收集,并发送到我绝对不拥有的云系统,我的数据将被该系统扣为人质。所有这一切的最终结果是,helpers 可以利用 Home Assistant 收集的数据做很多有趣的事情,但这确实需要在界面中进行大量点击(或者对于有此偏好的人来说,编写 YAML)。
2025-06-03 14:54:59
802
转载 LWN:作为内核开发者来尝试 Home Assistant 的总体印象!
成功安装和初始化后,一个 integration(集成)会向系统添加一个或多个“device(设备)”,每个 device(设备)都有一些用于报告数据的“sensor(传感器)”,以及可能改变其运行状态的“control(控件)”。我的 solar system(太阳能系统)有 22 块面板带 inverter(逆变器),每个都报告近十个 parameter(参数)(voltage(电压)、current(电流)、frequency(频率)、temperature(温度)等)。
2025-05-27 14:56:03
887
转载 LWN:FDP——更加自由的数据放置!
如果存在一个数据创建者,以及数据创建者与设备之间的多个层(例如,filesystem,即文件系统、device mapper,即设备映射器),那么最终决定数据去向的是最接近设备的那一层。Busch 说,可以使用的测量指标是来自硬盘的 write amplification 信息以及 p99 latency(p99 延迟),当生命周期相似的数据得到正确分组时,这两者都应该会降低。Busch 说,根据具有相似写入到丢弃(或覆盖)时间特性的操作对数据进行分组,并为其提供不同的 tag,将会产生影响。
2025-05-19 13:52:30
1106
转载 LWN:提高 FUSE writeback 性能!
在 2025 年 Linux 存储、文件系统、内存管理和 BPF 峰会 (LSFMM+BPF) 上的一次文件系统 (filesystem) 和内存管理 (memory-management) 联合会议上,Joanne Koong 主持了一场关于改进用户空间文件系统 (Filesystem in Userspace - FUSE) 层回写 (writeback) 性能的讨论。她说,问题在于页可能已经被 spliced (spliced),对于这些页,回写是无法取消的。“你不够值得信赖,不能让你这么做”。
2025-05-15 13:16:15
1148
转载 LWN:suspend 时冻结文件系统!
例如,Fstests(文件系统测试套件)就不测试恢复操作。在第一场会话中,大家一致认为,尝试按超级块的反向顺序冻结文件系统是有意义的,这样每一层更接近存储层(storage)的文件系统仍然保持活跃,以便能刷写(flush)数据。大家讨论了冻结文件系统的顺序,包括各种可能的死锁问题,但大多数有问题的用例已经得到解决,或者正在从内核(kernel)中移除。这些设备可能存在脏数据(dirty data),但当这些数据被刷写时,底层的那个文件系统会被冻结,因为块设备是在文件系统之后冻结的,因此会发生死锁。
2025-05-14 13:32:52
1139
转载 LWN:优化kernel内联函数调试信息!
因此,例如,一个存储在由寄存器指向的结构体 (structure) 成员中的参数,将表示为类似 "加载寄存器,添加偏移量,解引用,结束" 的序列。在 150,000 个不同的调用点上,内联函数的 228,000 个参数中,大约 83% 的位置可以表示为寄存器 (register) 的偏移量 (offset),通常是因为该参数存在于调用函数的栈 (stack) 上,或者作为指针 (pointer) 传递。在每个调用点都被内联的函数,比选择性内联函数造成的困惑要少,但支持它们会相当简单。
2025-05-13 13:29:30
1114
转载 LWN:让 CPU 调度器考虑 Cache!
最后一级缓存(LLC)(Last-Level Cache),离 CPU 最远,因此也是最慢的,但它往往是最大的,并且被最大数量的 CPU 共享。检测没有这种直接关系的任务中的缓存共享可能是困难的,如果它可能的话。如果感兴趣的线程一直在其他地方运行,它将被移动到所选的 CPU,在那里它将更接近其他线程,并且如果运气好,可以从与它们共享缓存空间中获益。因此,添加另一个启发式方法(“将进程的线程集中在单个缓存域中”)的补丁系列肯定会带来更多令人惊讶的交互,这些交互可能需要用更多的启发式方法来解决。
2025-05-12 13:17:37
1158
转载 LWN:UIO驱动的DMA地址!
他后来补充说,该提案“从根本上说是错误的且不安全的”,并且,如果他建议的方法不起作用,则唯一的选择是编写完整的内核驱动程序。当然,如果不破坏未知数量的现有驱动程序,就无法删除 UIO,但是可以将其冻结,目的是减少将来编写的使用 UIO 接口的驱动程序的数量。但是,拒绝新的 UIO 功能的真正结果似乎很可能是将这些功能推入到一组(可能更危险的)特定于驱动程序的 hacks 中,正如 DMA 地址显然已经在发生的那样。该系列还添加了一个新的 dma-buf 堆模块,用于创建简单的、缓存一致的 DMA 缓冲区。
2025-05-06 13:35:00
1190
转载 LWN:用户空间的 per-CPU memory!
本质上,这是缓存行对齐数组方法的变体,但分配器会将分配的数据紧凑地排列在每个 CPU 的区域内,从而减少这些区域之间的内存浪费。Desnoyers 首先表示,他的目标是帮助用户空间开发者更好地利用 restartable sequences (可重启序列),它通过在关键部分中断进程(如果进程在此时被迁移),从而促进对 per-CPU 数据的某些类型的访问。因此,该库首先在一个特殊的“初始化区域”中初始化一个 CPU 的内存,然后为每个 CPU 创建该区域的写时复制(copy-on-write)映射。
2025-04-23 13:30:04
1428
转载 LWN:buffer write 时不被“撕裂”!
在去年的 Linux 存储、文件系统、内存管理和 BPF 峰会 (LSFMM+BPF) 上,曾就原子写入 (atomic writes)进行过一次讨论,并随之发布了补丁,以在块层 (block layer) 中支持该特性,以及在 XFS 上支持直接 I/O (direct I/O)。他说,一切都只有 99.9% 的时间有效。他看到的一个问题是,开发人员一直在使用“原子”这个术语,因为这是 SCSI 和 NVMe 使用的术语,但随后人们希望 1MB 的原子写入能够工作,但这根本不是数据库开发人员所关心的。
2025-04-18 13:31:08
1538
转载 LWN:内核处理Rust代码的流程!
Hindborg 同意,但他也指出,在块(block)子系统中,开发者进行更改时并不担心 Rust 方面的问题。当他收到问题报告时,他会在一天内修复它,一切都会很好。如果 Rust 代码要通过常规的子系统树(subsystem trees),那么维护者至少应该对这些代码进行构建测试(build tests),并且应该有一个明确的方案来应对构建出错(build break)的情况。在他的结论中,他重申,自 6.10 版本以来,Rust 编译器的最低版本一直保持在 1.78.0,即使较新的版本已经获得了支持。
2025-04-16 13:42:02
1537
转载 LWN:GCC BPF 支持的进展!
然而,朝着这个目标前进的过程中,发现了一些 Clang 支持 BPF 的问题,需要进行长时间的讨论,以便为这两个项目找到前进的道路。目前,Ihor Solodrai 维护着 bpf-next 树的持续集成测试(他稍后在会议期间对此进行了介绍),该测试会测试每个提交的补丁,以确保验证器接受的内容没有退化。Song 说,这种 Clang 行为既是故意的,也是 BPF 特定的;他们说,如果外部结构是 CO-RE 可重定位的,那么从逻辑上讲,内部结构也应该是 CO-RE 可重定位的,无论它是如何进入该结构的。
2025-04-15 13:49:05
1490
转载 LWN:slab 分配器的sheaves以及任意上下文的分配功能!
总而言之,他说,来自 sheaves 层的初步结果是 promising(很有希望的),但它与 slab 调试的交互需要改进。(它是 slab 分配器的一部分)实现的工作会议,该版本期望可以从任何上下文中的 BPF 程序中调用。Hoang Nhat Pham 同意,他说他工作的系统具有大量的 CPU,但只有一个 NUMA 节点,从而导致大量的锁竞争,而 per-CPU 缓存可以改善这种情况。最后一个特性几乎是没有额外代价的,因为幸运的是,当请求到达时,分配器会有一个具有足够对象的 sheaf 存在。
2025-04-14 13:16:12
1472
转载 LWN:减少TLB压力的措施!
但是,内存管理子系统面向的是 PMD 级别的大页,在许多系统上,PMD 级别的大页大小为 2MB;如果内核可以使用更多的多尺寸透明大页(multi-size Transparent Huge Pages,mTHP),则可以更好地利用此功能,并在减少内部碎片的同时获得更好的 TLB 利用率。因此,即使没有 TLB 利用率的提高,使用更大的页面也是值得的。一位听众指出,AMD 在没有显式页表条目位的情况下执行 TLB 合并的能力很好,但这仅在应用程序已访问 mTHP 中至少一半的页面时才有效。
2025-04-10 13:34:11
1530
转载 LWN:墨西哥政府的开源经验!
这得到了回报,并且随着项目的发展,监管机构掌握了所需的背景知识,从而为项目铺平了道路。这是一场持续了三年的对话,最终达成了一个复杂的方案,即在后续的两个版本发布到生产环境后,可以将旧版本的代码添加到 Mifos 中。每当提出使用开源软件的想法时,由于缺乏相关知识,就会产生恐惧,但是由于决策者是政府官员,因此除了这种恐惧之外,还存在法律上的恐惧。在 López Obrador 政府的领导下,对这些项目的审查经常发现,他们可以使用开源软件,而不是采用提案中的昂贵的专有解决方案,因此这些项目需要进行切换。
2025-04-08 13:37:22
1464
转载 LWN:MM 的多重奏(huge page, page promotion, KSM, BPF)!
它的页面扫描需要 CPU 时间,它需要进行一些繁琐的调整才能匹配工作负载,并且它会引发安全问题,因为它可用于确定系统中是否存在具有给定内容的页面。通常,这意味着将频繁访问的(“热(hot)”)数据放置在最快且最靠近使用它的工作负载的内存中,而将不太频繁访问的(“冷(cold)”)数据降级到较慢、更远的内存中。BPF 程序几乎可以在任何上下文中运行,包括在中断处理程序中,甚至在不可屏蔽中断(non-maskable interrupt, NMI)的处理程序中,在这些处理程序中,获取锁的能力受到严重限制。
2025-04-07 13:20:33
1450
转载 LWN:保证可以分到连续内存的分配器!
保证 CMA 建立在 cleancache 之上,方法是在启动时分配一个物理上连续的内存区域,此时这种分配相对容易。不过,这些补丁相对较小,并且不会侵入未使用 CMA 的系统上的内存管理子系统,因此我们可能会看到超越内存应用程序在首次提出该想法大约 15 年后真正向前发展。如果内存可用,则可以快速分配。此后,大多数超越内存的工作都未被使用并已从内核中删除,但这个想法仍然存在,并且此补丁系列利用它来提供有保证的 CMA。多年来,人们付出了许多努力来避免对这种分配的需求,但在某些时候,它们是不可避免的。
2025-04-03 13:30:57
1486
转载 LWN:改进CPU漏洞防护措施的配置方式!
用于选择缓解措施的内部逻辑 (internal logic) 也受到了审阅者的广泛关注,尽管仅以代码风格注释的形式出现,但也得到了清理。通过 Kaplan 的更改,功能应该相同,但是该实现已分为 "select" (选择) 、 "update" (更新) 和 "apply" (应用) 函数,用于内核知道的每种缓解措施。select 函数确定是否应启用缓解措施, update 函数允许根据已选择的其他缓解措施来更改缓解措施的特定配置,而 apply 函数则完成将缓解措施应用于内核的实际工作。
2025-03-31 13:12:37
1511
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人