mounter625-CSDN博客

原创 Custom out-of-memory killers in BPF

内核无法发出“谁愿意被杀”这样的广播，因此 OOM 杀手必须运用一套启发式方法来选择受害者——既要尽可能多地释放内存，又要尽量减少用户的痛苦。当整个系统（或近年来的任意控制组）内存紧张到无法继续分配时，它会被“召唤”出来，其任务是终止一些进程以释放足够的内存。为此，内核提供了一些可调节的“旋钮”，允许某些进程自愿（或被强制）优先成为 OOM 杀手的目标。在默认配置下，内核会对系统内存进行超额分配，也就是说，它允许进程分配的内存总量超过系统可提供的总量（即物理内存与交换空间之和）。截至目前，评论还不多。

2025-05-02 04:54:12 579

原创 Better debugging information for inlined kernel functions

其他方法，比如 tracepoints 和 Linux 安全模块（LSM）钩子，也能用于选择性内联函数，但 Liu 认为这些并不能真正替代正常的函数跟踪，因为在调试内核问题时，往往要到深入分析阶段才能明确需要跟踪哪些函数。最常见的编译器优化之一是函数内联：将函数体的代码直接嵌入调用者中，以避免函数调用的开销，并可能带来更多的优化机会。这就可能导致一种情况：一个函数仍然出现在二进制文件的符号表中（因为部分调用未被内联），但在跟踪时却无法看到调用它的地方（因为热点调用已被内联，该函数符号不再代表这些调用）。

2025-05-01 05:53:46 480

原创 Cache awareness for the CPU scheduler

最靠近CPU的L1缓存通常是CPU私有的，而后续的缓存级别（虽然更慢，但通常更大）则被多个CPU共享。将任务从一个CPU迁移到另一个CPU，可能会使其失去原先缓存的数据，从而影响性能。原先的代码即使任务已经运行在同一个LLC域内，仍然会将其迁移到“热点”CPU，而这时任务本就已经在共享最大级别的缓存，再次迁移反而会带来性能损失而非提升。补丁为描述地址空间的。因此，这组补丁所引入的又一条启发式逻辑（“将进程的线程集中在一个缓存域中”）势必会带来更多意料之外的交互，可能还需要再引入更多启发式规则来加以协调。

2025-04-30 01:29:17 737

原创 Dancing the DMA two-step

Christoph Hellwig回应称，即使设备能够处理高度碎片化的IOVA空间，但在面对连续的IOVA范围时，通常仍然能获得更好的性能表现。CPU的内存缓存与DMA操作结合使用时，可能导致对内存中数据的一致性视图出现问题——例如，设备无法看到只存在于CPU缓存中的数据。中保存设备可见的物理地址范围。说实话，我怀疑现在还有多少真正支持scatter-gather的设备存在明显的限制，以至于需要通过合并DMA段来获得实质性好处——我一直在想，现在也许应该默认关闭这种行为，改为让调用者通过属性显式请求。

2025-04-29 04:09:00 642

原创 Inline socket-local storage for BPF

对于像 Meta 这样清楚每个 socket 的 BPF 程序需要多少存储空间的公司来说，这样可以预先配置合适的大小，从而完全避免双重解引用和缓存未命中的问题。Lau 解释说，目前创建每个 socket 的 BPF map 时，所用的内存会计入创建该 map 的用户空间程序。另一位开发者提出，如果一个 BPF 程序在内联存储中预留了空间，但随后被用户空间重新加载——那么会进行新的分配（让旧分配成为垃圾），还是以某种方式复用旧分配？遗憾的是，本次讨论在最终敲定设计方案之前，就已经到达了预定的会议结束时间。

2025-04-29 03:44:20 674

原创 ACCESS_ONCE() and compiler bugs

Christian 的补丁集在必要的地方将 ACCESS_ONCE() 调用替换成了 READ_ONCE() 或 ASSIGN_ONCE()。代码注释中建议，今后应优先使用这些新宏而不是 ACCESS_ONCE()，但目前大多数已有的 ACCESS_ONCE() 调用尚未改动。再次强调，这需要进行细致的审核，而且未来的新增代码仍可能引入新的 buggy ACCESS_ONCE() 调用。减少脆弱性的一种方法是修改受影响的 ACCESS_ONCE() 调用，让它们指向相关非标量类型中的标量部分。

2025-04-27 21:39:31 800

原创 ACCESS_ONCE()

如果代码总是在持有相关锁的情况下访问共享变量，且该变量只会在锁释放后由其他线程修改，那么编译器就不会引入这些微妙的问题。只有在访问共享数据时既没有加锁，也没有明确使用屏障的地方，才需要像 ACCESS_ONCE() 这样的构造。在这样的系统上，编译器为了生成性能最优的代码，必须仔细选择哪些值保存在寄存器中。这个宏的功能其实正如其名字所描述的那样：它的目的是确保生成的代码对传入参数的访问恰好发生一次。这段代码是自适应自旋的一部分，目的是在当前持有者释放互斥锁后，尽快获取它，而不必进入睡眠状态。

2025-04-27 18:34:11 512

原创 Support for atomic block writes in 6.13

但显而易见，这种双写机制带来了显著的性能开销，尤其是在写入密集型的场景中。正如 2024 年 LSFMM+BPF 峰会期间所讨论的，一些云服务提供商已经开始宣传其支持基于 ext4 文件系统的原子写入功能，前提是启用了 bigalloc（大块分配）功能，该功能使文件系统采用基于簇（cluster）的分配方式，而非按块分配。需要注意的是，ext4 文件系统不支持大于系统页大小的块大小，因此在页大小为 4KB（如 x86 系统）上，ext4 无法使用 16KB 的块大小，因此也无法支持该大小的原子写入。

2025-04-26 12:41:53 658

原创 Some nonstring turbulence

但 Fedora 42 已经发布，而 Fedora 的开发者选择在默认编译器中使用 GCC 15 的预发布版本，这一决定无论好坏，延续了 Red Hat 的一贯传统。为了解决这些问题，Torvalds 自行制作了一系列修改，并在发布前两小时将它们直接合入主线，其中包括一个修复 ACPI 子系统警告的补丁，以及另一个修复多个警告（包括上文示例）的补丁。不幸的是，这些最后时刻的更改破坏了在 GCC 15 预发布版本之前的所有编译器上的构建，这可能会给未使用 Fedora 42 的开发者带来一些不便。

2025-04-25 15:19:08 786

原创 Freezing filesystems for suspend

在那次发布时，他遇到了一些锁相关的问题，并在今年的会议开头再次提起这些问题。当时 VFS 层与块设备层之间的冻结逻辑存在一些锁顺序反转问题，但现在这些问题已经被理清，“就我看来，从锁的角度来说应该是安全的”。虽然他已经有一个解决方案，尽管实现比较难看，但他认为如果能有一种通用 API，其他文件系统也能从中受益，在系统挂起-恢复周期中提供更好的一致性保证。这些设备可能有脏数据需要刷写，但当数据刷新时，底层文件系统已经被冻结，因为块设备是在文件系统之后被冻结的，这可能导致死锁。

2025-04-25 13:06:10 1016

原创 VFS write barriers

在 2025 年的 Linux 存储、文件系统、内存管理与 BPF 峰会（LSFMM+BPF）的文件系统议题中，Amir Goldstein 希望继续讨论一个他在 2023 年峰会最后一场会议中简要介绍过的特性：文件系统的“写屏障（write barriers）”。在会议稍后的讨论中，Jeff Layton 提问后，Goldstein 进一步解释了他的使用场景：目标用户是拥有“非常大数据集”的用户，他们需要云同步、数据复制等功能。在他的应用中，变更日志用于记录所有文件系统的变更，以确保没有遗漏；

2025-04-24 16:05:57 667

原创 Code signing for BPF programs

为了解决这一问题，Boscaccy 考虑过几种方案，包括将执行重定位、创建 BPF 映射等任务的 BPF 程序加载器移入内核，或采用一种基于 “轻量骨架（light skeletons）” 的方法，让一个 BPF 程序为另一个程序执行重定位。重要的是，这个第二签名不仅覆盖修改后的 BPF 程序，还包括原始签名，从而建立一条信任链：从最初构建 BPF 程序的一方，到签名过的 libbpf 加载器，再到最终提交给内核的对象。签名密钥的分发管理也是一大难题，尽管这并非该方案独有的问题，Wang 补充道。

2025-04-24 03:30:49 673

原创 DMA addresses for UIO

一旦加载该模块，用户空间驱动就可以打开相应的 /dev/uioX 设备，将内存区域映射到自己的地址空间，利用该映射对设备进行编程，并通过读取设备文件描述符来等待中断。而在更复杂的系统中，这种“物理地址”可能处于设备所在总线的独立地址空间中，甚至还需要通过 I/O 内存管理单元（IOMMU）进行地址转换，并进行相应的编程。他还补充说，这项提案“从根本上就是错误和不安全的”，并表示如果他的建议无法满足需求，那么唯一的替代方案就是编写一个完整的内核驱动。如今，在一些人看来，UIO 所提供的价值甚至可能是负面的。

2025-04-23 15:08:02 737

原创 Indirect calls in BPF

Protopopov 对这个方案并不确定，因为它并不能解决静态键引用多个映射的问题，但 Starovoitov 建议他尝试添加一个额外的间接层，使静态键可以指向多个映射组成的表。验证器在执行死代码消除及其他转换时，会保持这些指令地址的更新状态——这正是需要一种专用映射类型的原因，而不是仅依赖于 BPF 程序中的硬编码偏移。在目前的代码状态下，尝试创建第二个使用同一个指令集映射的 BPF 程序实例会直接失败——因为当验证器要修改指令位置时，该映射已经被冻结，导致验证过程失败。而对于静态键，用于运行时更新的。

2025-04-22 15:24:22 484

原创 The problem of unnecessary readahead

在页大小较小的系统上，这些填充数据毫无用处，完全可以保留在磁盘上不动，但预读机制仍然会将它们加载进页缓存，带来了无意义的 I/O 并浪费内存。文件中的空洞（hole）可以在内核中标记，当进程访问这些空洞时，直接映射到零页（zero page）。Singh 指出，在这些场景中，即使不需要的数据位于映射区域之外，预读机制依然会把它们加载进来。随着本场讨论（以及整场会议）进入尾声，Hildenbrand 提出，与其尝试对这些“边角案例”进行优化，不如干脆在遇到文件空洞时立即停止预读，或许这就足够了。

2025-04-19 15:08:39 428

原创 Tracepoints for the VFS?

在 2025 年的 Linux 存储、文件系统、内存管理和 BPF 峰会（LSFMM+BPF）上，Ted Ts’o 主持了一场讨论，探讨 VFS 是否应该添加 tracepoint，以及其带来的实用性是否能胜过对 ABI 的担忧。Mathieu Desnoyers 是最初在 2008 年开发 tracepoint 的人，他指出，在过去关于是否添加 tracepoint 的讨论中还曾提出过另一种担忧：tracepoint 可能被滥用于执行劫持。在这个背景下添加 tracepoint 是合理的，有助于开发。

2025-04-19 15:02:21 653

原创 Memory controller performance improvements

在 2025 年的 Linux 存储、文件系统、内存管理和 BPF 峰会的内存管理专题中，Shakeel Butt 主持了一个会议，讨论内存控制器的当前状态以及如何降低其开销。Hocko 表示，目前的基础设施已被很好地优化，因此添加一个允许返回过期数据的接口，或许确实是合理的下一步。也有人请求提供关于“内存余量”的更好信息——即一个控制组还可以使用多少内存，或者说，在耗尽资源前还能再使用多少。他提到，去年他主持了一个专门讨论弃用版本 1 内存控制器的会议，这是逐步淘汰对版本 1 控制组支持的关键步骤。

2025-04-18 01:08:05 585

原创 Parallel directory operations

这些补丁的主要障碍在于：虽然目录的 i_rwsem 被作为共享锁获取，但目录项（dentry）却是用独占锁来保护的，这就带来了大量潜在的死锁可能性。比如说，在使用 NFS 的场景中，如果多个文件在同一个目录中被创建，这些操作会在客户端被串行化，这意味着在真正执行前需要进行大量网络往返。Brauner 表示他并不喜欢引入大量新的 inode 操作，但如果这个思路可行，可以为现有操作添加一个异步形式，只对选择启用该特性的文件系统启用。后缀的新 inode 操作，“虽然看起来有点丑”，但这只是“表面问题”。

2025-04-17 18:17:13 888

原创 Improvements for the contiguous memory allocator

简而言之，在具有大页大小的系统中，为了使用 CMA，需要预留极大的内存区域。CMA 区域的大小也必须是页块大小的整数倍。但 CMA 的缺点是，有时（正如两天前的讨论中提到的），那些“可移动”的分配实际上可能并不可移动；与最初的 cleancache 设计一样，可保证的 CMA 会存储干净的、由文件支持的页面，这些页面可以按需丢弃。另一种方法是将 ARCH_FORCE_MAX_ORDER 配置参数设置为较小的值，比如 7，这会导致页块变小，从而减少内存浪费，但同时也会让大页的分配变得更困难。

2025-04-17 16:56:21 757

原创 Topics from the virtual filesystem layer

在 VFS 中，有一种称为匿名挂载命名空间（或者“分离挂载树”，看你怎么叫）的概念，这种挂载命名空间存在于内核中，但进程无法使用 setns() 进入它；他指出，这是个问题，因为例如一个进程可以持有该命名空间的文件描述符，从而将一些对象钉在内存中，但用户空间却无从得知是谁造成了内存被钉住。内核中有一个用于挂载命名空间的红黑树，但它是通过为每个命名空间分配的序号来索引的；在高并发场景下，该机制带来了 3-5% 的性能提升，“这显然是很不错的”，但他认为，这只是将可扩展性问题往后推了一步。

2025-04-16 19:40:24 920

原创 Automatic tuning for weighted interleaving

Liam Howlett 回应称，这种调整的职责显然应在用户空间，因为内核不可能知道用户的意图。Gregory Price（最初设计加权交错功能的人）指出，目前还没有接口允许一个进程调整另一个进程的权重，而这正是用户空间方案所需要的。他强调，带宽才是限制系统性能的最终因素，比单次内存访问的延迟更重要。权重值也应尽可能小；因为权重实际上是指在切换节点之前从该节点分配的页面数量，权重越小，分配分布得就越快。Hocko 的回答是否定的，他表示 NUMA 接口最初是为静态硬件设计的，甚至在当前的系统中也表现不佳。

2025-04-15 23:36:43 484

原创 The future of 32-bit Linux

通常来说，前沿技术往往生命周期较短，很快就会被下一代替代；而那些能以更低成本完成任务的技术则可能流行多年，甚至几十年。这一规律在摩托罗拉 68000 架构、Arm9 CPU 核心，以及 Raspberry Pi Zero 开发板上都得到了体现——它们都比多个更先进的替代品存活得更久。正是这种现象让期待 highmem 终结的人们燃起希望，因为需要 highmem 的硬件通常是五年前的先进产品，预计会在未来五年内逐渐退役。

2025-04-15 17:44:55 1113

原创 The state of the memory-management development process, 2025 edition

但如果不把 mm-unstable 推送到 linux-next，里面的补丁就无法获得更广泛的测试，最终会影响 mm-stable 的稳定性。Morton 说，有些改动可以直接进入 mm-next，而 mm-unstable 将成为规模较大或尚未审查代码的第一站，具体情况由他判断。Liam Howlett 表示，除非是某个大型项目的一部分，他通常不会接受纯清理性质的补丁，因为这些清理操作常常会破坏一些微妙的东西。总体来说，Morton 表示，如果有人希望他做某件具体的事，直接告诉他就好。

2025-04-15 03:36:41 893

原创 Managing multiple sources of page-hotness data

这类来源之间存在一定共通点。他指出，现在需要的是一种高效的数据结构来聚合这些方法产生的数据。Jonathan Cameron 在 2025 年的 Linux 存储、文件系统、内存管理和 BPF 峰会的内存管理专题中指出，这类数据的来源正在不断增多。Cameron 本人关注的是 CXL 的“热度监控单元”，它可以提供某个 CXL 内存模块中哪些页面被访问过的详细数据，但除此之外还有很多其他数据来源。不同的数据来源提供的信息各异，可能包括也可能不包括虚拟地址、进行访问的 NUMA 节点，或是访问发生的时间。

2025-04-12 13:35:57 857

原创 Inlining kfuncs into BPF programs

当校验器在校验过程中遇到对该函数的调用时，会设置一个特殊的校验状态，用于传递参数和 BPF 栈的信息到用于校验该函数实例的代码中。这个方法的问题在于，当前的 BPF 并不依赖架构——相同的程序可以在任何支持 BPF 的架构上无需修改地运行——但 kfunc 可能包含架构相关的代码。在他最初的 RFC 中，他聚焦于 bpf_dynptr_slice()，并展示了通过内联可以消除来自 switch 和 if 语句的跳转，在他的合成基准测试中带来 1.53 倍的加速。内联的理由，和以往一样，是为了优化。

2025-04-12 13:26:22 657

原创 Atomic writes for ext4

Mujoo 描述了 ext4 原子写入支持的路线图：基于 bigalloc 的多块写入补丁集，以及为 ext4 添加 extsize 和 forcealign 支持的补丁集，目标是在 Linux 6.16 中合并。ext4 的 bigalloc 特性可以消除非对齐 extent 的问题，因为文件系统的簇大小可以设置为例如 16KB，这样所有内容都将在这些边界上对齐。但这是一个针对整个文件系统的设置，即使只需对少数文件进行原子写入，也必须使用这个设置，而且需要重新格式化现有文件系统才能启用。

2025-04-11 19:27:13 754

原创 Preparing DAMON for future memory-management problems

Park 表示，目前已有多个方案在探讨如何获取这些数据，包括工作集报告、来自 CXL 控制器的热度监测、访问位扫描（当天早些时候曾讨论过）、AMD 的基于指令采样功能提供的数据、多代 LRU 提供的数据等等。他还表示，随着来自多个来源的访问数据越来越细粒度，DAMON 所跟踪的区域将变得更细，整体数据密度更高，DAMON 的跟踪负担也将随之增加。他希望合并自己在生成 NUMA 使用率和空闲空间目标度量方面的工作，并实现一个“开箱即用”的分层模块，适合主线内核集成，能自动识别系统的内存层级。

2025-04-11 15:44:35 593

原创 Improving hot-page detection and promotion

对此 Rao 回应说，目前的实现中，只要观察到第一次访问就会提升页面，因此后续访问的数据缺失不是问题。另一种可能性是，系统可以扫描最快级别内存中的页面，观察某个地址空间的页面目前主要聚集在哪些节点上，然后将其他页面提升到这些节点。Rao 表示，他的实现总体上显著降低了应用程序的延迟，但并未具体回应锁的问题。该线程会维护一个进程地址空间的列表，并对每个地址空间执行“访问位（A-bit）”扫描：清除 PTE 中的“已访问”位，然后稍后再次扫描，看哪些 PTE 的该位被重新置位，从而判断其是否在此期间被访问。

2025-04-10 15:40:45 1014

原创 Two approaches to better kernel samepage merging

他表示，在代码打补丁时，可以为修改后的文件创建一个新的 inode，并存储在相关的虚拟内存区域中。内核目前的 uprobes 机制可以为运行中的进程打补丁，但它会影响所有运行该代码的进程，而他希望将影响限定在单个进程内。因此，他设想新增一个系统调用用于代码补丁，在其中创建一个新的覆盖层，用于跟踪每个用户对某个二进制文件的修改。不过，这种机制的最大限制是，一旦两个页面产生差异，它们就不再被合并，即使它们未来的内容再次一致也是如此。系统调用，该调用接受一个分区名称作为参数，并返回一个表示该分区的文件描述符。

2025-04-10 15:32:48 918

原创 Per-CPU memory for user space

Desnoyers 开场表示，他的目标是帮助用户空间开发者更好地利用可重启序列（restartable sequences），该机制允许在关键区段中，如果进程被迁移，则中断其访问，从而便于访问 per-CPU 数据。这本质上类似于以缓存行对齐的数组方式，但分配器会在每个 CPU 的区域内进行紧凑打包，从而减少不同 CPU 区域间的内存浪费。他表示，内核的 per-CPU 分配器会在每个 CPU 上映射一段地址空间，用于访问该 CPU 的本地内存空间；目前，他采用了一种“不太方便的替代方案”，通过几次。

2025-04-09 15:56:11 1177

原创 The rest of the 6.15 merge window

该子系统过去存在争议，但 2024 年的维护者峰会达成共识，同意将其合并。尽管这看起来可能不太直观（或不够高效），但这里的逻辑是，许多现有的 epoll 事件循环可以轻松地部分转换为基于完成（completion-based）的模型，但仍受限于一个或少数几个仍基于就绪状态（readiness-based）的事件类型。BPF 子系统增强了对包含循环的程序的验证能力，新增了一些 load-acquire 与 store-release 指令，支持在 BPF 程序中修改文件的扩展属性，并引入了一个带定时的。

2025-04-08 16:16:19 1027

原创 An update on pahole

Pahole（原名“Poke-a-hole”）是一款用于探索和编辑调试信息的多功能工具，就像“瑞士军刀”一样。目前，Pahole 还参与了内核的构建过程，将不同编译器生成的信息重新整理为 BPF 验证器可用的格式，尽管将来有计划使其变得不再必要。Pahole 的维护者 Arnaldo Carvalho de Melo 在 2025 年的 Linux 存储、文件系统、内存管理与 BPF 峰会上分享了该项目的一些最新进展。感兴趣的读者可以在这里找到他的演示文稿。

2025-04-08 15:37:39 812

原创 A new version of modversions

该工具读取并解析已经经过预处理的 C 源文件，收集该文件导出的每个符号的定义，计算每个定义的校验和，并以构建流程可以访问的格式输出结果。然后，内核中的 modpost 工具使用这些信息生成一个 C 源文件，该文件填充一个特殊的 ELF 段，其中包含符号（导出和使用的）及其校验和。不过，总体而言，评审者们对这个补丁系列当前的形式还是比较满意的。裸露的 union 类型与 Rust 的编程哲学相悖，因为它无法保证任何时刻所访问的是正确的字段，因此社区有人建议采用一种更复杂的方式来实现类似功能。

2025-04-07 20:00:17 685

原创 A strange BPF error message

在他演讲的最后阶段，他还讨论了优化过程中改变函数签名所带来的问题——这是 José Marchesi 在前一场会议中也提出过的问题。可惜的是，这种做法并不适用于 BPF 程序。优化器将一个函数内联到另一个函数中，发现程序在读取一个未初始化变量（这属于未定义行为，优化器认为这种行为不可能发生），于是判断这段代码是不可达的。这在某种程度上是有效的，因为生成的程序不会再被拒绝，但也可能掩盖了真实的 bug。在 C 语言中这不是非法的，因为被调用的函数可能会对变量进行初始化，因此 Clang 不会发出警告。

2025-04-07 18:08:37 751

原创 Page allocation for address-space isolation

保护进程即将读取的页面本无意义，但由于页面缓存中可能包含进程无法访问的数据，因此不能将整个缓存统一标记为非敏感。因此，当前的实现是：即使只需要一个页面，也会分配整个页面块，然后释放zone锁，执行TLB失效，再重新获取zone锁。这种方式可以工作，但存在一个令人担忧的情景：如果系统中的所有CPU同时尝试分配敏感页面，它们都会执行上述“舞步”，从而互相触发TLB失效，造成冲击。Jackman继续表示，如果清零的开销过大，那么分配器可能就需要重复前述的“取消映射舞步”，或者使用页面标志来逐页进行清零。

2025-04-05 22:21:48 541

原创 Supporting untorn buffered writes

在去年的 Linux 存储、文件系统、内存管理与 BPF 峰会（LSFMM+BPF）上，曾讨论过原子写入问题，并附带了一些补丁，为块层和 XFS 的直接 I/O 添加该功能。这些工作已被合并，但讨论的另一部分内容是是否为缓冲 I/O 添加该功能，部分原因在于 PostgreSQL 数据库目前需要采用许多复杂手段来确保写入在发生错误或崩溃时不会“撕裂”（即部分写入）。

2025-04-05 20:48:04 853

原创 The state of guest_memfd

在有硬件支持的实现中，主机如果尝试访问 guest 的私有内存，甚至可能触发机器检查，导致系统崩溃。仍可以通过将私有内存从主机的 direct map（直接映射）中移除，来实现一定程度的设备隐私保护，使得主机无法对其寻址。然而，主机依然保留对这部分内存的访问权限，这意味着它可以轻松地查看这些内存中的数据，即便这些数据是虚拟机希望保密的。子系统中分配内存，但随后将其转换为普通 folio，如果需要，可以将其映射或拆分，以便将其中较小的部分在共享与私有之间转换。但如果主机尝试访问私有页，依然会触发总线错误。

2025-04-05 16:49:20 902

原创 An update on GCC BPF support

pahole 的维护者 Arnaldo Carvalho de Melo 表示，pahole 可以通过检查 BTF 的生成者来识别，因此这并不成问题——尽管长远目标是从 BPF 编译流程中移除 pahole，所以 GCC 最终还是需要生成符合内核预期的标签。总体而言，该项目正稳步向对 BPF 的全面支持推进，目前在使用 Faust 正在开发的补丁后，大多数自测已能通过。然而，朝着这一目标的推进也暴露了 Clang 对 BPF 支持中的一些问题，需要进行深入讨论，以为两个项目找到共同的前进道路。

2025-04-04 16:30:25 782

原创 Approaches to reducing TLB pressure

但目前内存管理子系统主要支持的是 PMD 级别的大页，在多数系统上大小为 2MB，这容易因内部碎片而增加内存压力，反而抵消了大页带来的好处。如果内核能使用更多不同大小的透明大页（mTHP），就能更好地利用这一特性，在降低内部碎片的同时提升 TLB 利用率。他还在努力减少页面回收时所需的 TLB 刷新次数。因此，即使没有 TLB 利用率的提升，使用更大的页面也是值得的。在会议即将结束时，David Hildenbrand 指出，在 AMD CPU 上，要实现 TLB 合并，某一范围内页面的页表项必须一致。

2025-04-04 15:43:05 466

原创 The end of tasklets

对于这样一个重要的新特性来说，这是一个相对较快的进度，但 WQ_BH 依赖于已有的工作队列 API，而 tasklet 机制已经被开发者们希望移除多年。Linus Torvalds 建议，与其修复 tasklet，不如在 softirq 上下文中引入一种新的工作队列，以提供比普通工作队列更低的延迟。工作队列维护者 Tejun Heo 实现了这个想法，推出了一种新的工作队列类型——WQ_BH，它在原子上下文中执行，并且保证在同一 CPU 上运行。要移除整个软件中断子系统，将是未来的任务。

2025-04-02 21:51:40 792

【电信基础设施】OTII服务器系列产品演进与应用：从1U到2U及OTII-E的边缘计算部署方案综述

内容概要：本文介绍了开放电信IT基础设施（OTII）的发展历程及其应用场景。OTII是由英特尔领导的项目，旨在为边缘计算提供标准化的服务器解决方案。自2017年启动以来，OTII发布了多个版本的规范，涵盖了1U、2U和OTII-E三种类型的服务器。这些服务器支持不同的处理器架构（如Xeon-D和Xeon-SP），并适用于多种边缘计算场景，包括5G小基站、边缘数据中心、电力控制站、制造行业、边缘网关以及本地AI应用。此外，OTII服务器在硬件上支持高性能计算和AI加速，能够满足低功耗、低成本、易于部署和维护的需求。文档还展示了OTII服务器在不同行业的设计胜利案例，并提供了性能数据，特别是在推理任务上的表现。适合人群：对边缘计算、电信基础设施及服务器技术感兴趣的工程师和技术管理人员。使用场景及目标：① 5G小基站部署，提供低成本、低功耗的解决方案；② 边缘数据中心，实现快速部署和维护；③ 电力控制站，支持视频监控和AI计算；④ 制造业，用于TSN网络和5G连接；⑤ 边缘网关，作为标准化网关平台；⑥ 本地AI应用，提供高性能计算能力。其他说明：OTII服务器不仅支持传统的计算任务，还特别针对AI推理进行了优化，能够支持多种精度的模型部署。此外，OTII服务器在不同行业的应用案例表明其广泛的适应性和灵活性，是未来边缘计算的重要组成部分。

2025-05-01

【服务器管理】IPU Redfish服务器实现计划：硬件与软件更新接口及用例介绍

内容概要：本文档概述了Intel IPU Redfish服务器的实施计划及其关键特性。Redfish服务器旨在为IPU提供远程管理和更新功能，采用分阶段实施方法。第一阶段包括支持Redfish的IPU SDK基线和软件更新；第二阶段涉及获取系统硬件和软件信息；第三阶段则涵盖安全启动和认证。文档还介绍了具体的使用案例，如IMC和ACC镜像更新，并详细列出了相关API端点。此外，文档提到了当前面临的挑战，如内存管理、安全性期望以及缺少参考ISO映像和安装程序，并规划了后续步骤，包括确保BMD更改减少IMC重启次数、使Redfish解决方案达到生产就绪状态等。适合人群：具有硬件或软件开发背景，特别是对服务器管理、固件更新或Redfish协议有一定了解的技术人员。使用场景及目标：①了解Redfish服务器在IPU上的具体实现和部署流程；②掌握IMC和ACC镜像更新的具体API端点及其操作方式；③识别并解决实施过程中遇到的主要技术挑战。阅读建议：文档内容较为专业和技术化，建议读者结合实际应用场景来理解各部分细节，并关注实施过程中可能遇到的问题及其解决方案。

2025-04-29

【OpenVINO 2024.1】增强型生成式AI工作负载支持：大规模语言模型性能优化与广泛技术支持

内容概要：OpenVINO 2024.1 引入了多项新特性和优化，旨在提升生成式AI工作负载的性能并扩展对大型语言模型（LLM）的支持。新版本支持最新的SOTA模型如Llama3、Phi-3等，并优化了Mixtral、URLNet、Stable Diffusion 1.5等多个模型的性能。此外，OpenVINO增加了对INT8 PyTorch模型的微调支持以及混合后训练量化技术，提升了推理效率。部署方面，OpenVINO提供了NPU插件预览、JavaScript API集成和ARM处理器上的FP16推理支持。新的OpenVINO笔记本展示了各种应用场景，包括文本生成、图像分类、对象检测等。通过与Optimum集成，OpenVINO实现了便捷的模型转换和量化流程。适合人群：对AI和深度学习感兴趣的开发者，特别是希望提升生成式AI和大型语言模型性能的研究人员和技术人员。使用场景及目标：① 使用最新的SOTA模型进行高效推理；② 利用混合后训练量化技术优化模型性能；③ 在不同硬件平台上部署优化后的模型；④ 探索和实践生成式AI的各种应用案例。阅读建议：此资源详细介绍了OpenVINO 2024.1的新特性及其应用场景，建议读者结合实际需求选择感兴趣的部分深入研究，并尝试动手实践相关功能。

2025-04-27

【密码学与信息安全】基于SMx算法的加密性能优化：Intel QAT引擎在Sapphire Rapids平台上的实现与应用

内容概要：本文介绍了Intel的QAT（QuickAssist Technology）引擎对国密算法（SMx）的支持及其性能表现。文章首先概述了SM2、SM3和SM4三种国密算法的标准和特性，接着详细描述了QAT引擎软件栈及其硬件加速器对这些算法的支持情况。通过与BabaSSL软件实现的对比测试，展示了QAT引擎在不同应用场景下的显著性能提升，尤其是在SM2签名、SM4-CBC、SM4-GCM和SM4-CCM等算法上分别获得了36倍、15倍、10倍和10倍的性能增益。此外，文章还探讨了QAT引擎在多核环境下的性能优化策略，包括多缓冲技术、小包卸载（SPO）支持以及QAT引擎与OpenSSL/BabaSSL的协同工作模式。适合人群：具备一定计算机安全和加密技术基础的研发人员，特别是关注国密算法和高性能加密解决方案的技术专家。使用场景及目标：①评估QAT引擎在实际应用中的性能优势，特别是在高负载和大数据量场景下；②理解QAT引擎如何通过硬件加速提高SMx算法的执行效率；③为选择合适的加密实现提供参考，确保在不同规模的应用环境中获得最佳性能。阅读建议：本文涉及大量技术细节和性能数据，建议读者结合自身需求和技术背景进行深入研究。对于希望深入了解QAT引擎内部机制的读者，可以进一步探索相关开源项目和文档，如GitHub上的QAT_Engine仓库。

2025-04-26

### 文章总结：Intel Ethernet Products 和 IPU 产品路线图及特性概述

内容概要：本文档详细介绍了英特尔以太网产品部门（Intel Ethernet Products Division）的产品路线图和技术进展。主要内容涵盖200G、400G和800G以太网适配器及控制器的规划与特性，包括E830系列、E810系列、E610系列等产品的技术规格、性能指标和未来发展方向。此外，文档还涉及了新一代IPU（智能处理单元）的发展蓝图，如基于Mt. Evans架构的E2100 SoC，以及其在云、边缘计算和网络应用中的具体应用场景。文中特别强调了新产品的安全性和虚拟化支持，如SPDM 1.1、Secure Boot、FIPS 140-3等安全特性，以及对SR-IOV、RDMA、NVMe等技术的支持。适用人群：适用于对数据中心网络硬件有深入了解的技术专家、系统架构师和网络工程师。使用场景及目标：①了解英特尔以太网适配器和控制器的技术规格和发展趋势；②评估英特尔新一代IPU在云、边缘计算和网络应用中的适用性；③研究以太网适配器和控制器在高性能计算、存储和虚拟化环境中的部署方案。阅读建议：本文档内容较为专业，建议读者先熟悉以太网适配器、控制器及IPU的基本概念和技术背景，重点关注各产品线的技术特点和应用场景，并结合实际需求进行深入研究。同时，关注文档中提到的安全性和虚拟化特性，这对于提高系统的可靠性和性能至关重要。

2025-04-26

【人工智能硬件】面向企业级AI推理的多GPU解决方案：Intel Arc在中国市场的布局与优化

内容概要：本文为英特尔中国团队于2023年6月发布的关于企业级AI推理解决方案的进展报告。报告指出，AI推理是当前中国数据中心的主要工作负载，占比达67%，并预计将持续增长。英特尔提出了一种基于多GPU的AI推理和微调解决方案，旨在为企业提供高性能和高性价比的选择。该方案聚焦于优化软件栈（如oneCCL、IPEX-LLM等）以提升跨GPU通信性能，并计划推出更大显存、更高带宽和计算能力的GPU产品。此外，报告还分析了市场趋势，预测到2027年中国边缘计算市场将占AI工作负载部署的35%，并强调了英特尔在这一领域的战略部署和发展计划。; 适合人群：对AI硬件架构、云计算及边缘计算感兴趣的IT专业人士、数据科学家以及企业决策者。; 使用场景及目标：①了解当前及未来几年内AI推理在中国市场的地位和发展趋势；②评估英特尔多GPU解决方案相对于NVIDIA产品的优劣势；③探索英特尔在AI推理和微调方面的技术创新及其对企业级应用的影响。; 其他说明：报告中提供的数据来源于IDC等权威机构，并结合了英特尔自身的市场洞察。报告不仅展示了英特尔的技术优势，还明确了其在未来几年内的市场定位和发展方向。

2025-04-26

### 文章总结：基于英特尔架构的传感器融合技术在智能交通系统中的应用

内容概要：本文档详细介绍了基于英特尔架构的传感器融合技术在智能交通系统（ITS）中的应用，特别是针对车路协同（V2X）和智能交通管理系统的场景。文档涵盖了传感器融合的基本原理、传感器类型（摄像头、毫米波雷达、激光雷达）、数据处理流程（如3D点云处理、深度学习推理）以及具体的应用案例和技术挑战。此外，文档还探讨了多传感器融合的优势，如提高感知精度和可靠性，并提出了未来的发展方向，包括国际标准制定、公开数据集的需求以及功能安全（FuSa）和预期功能安全（SOTIF）的重要性。适合人群：具备智能交通系统基础知识的研发人员、工程师及对传感器融合技术感兴趣的学者。使用场景及目标：①理解传感器融合在智能交通系统中的关键作用；②掌握不同类型传感器的特点及其在交通感知中的应用；③学习基于英特尔架构的传感器融合解决方案的具体实现方法和技术细节；④探索多传感器融合带来的技术优势和面临的挑战。其他说明：本文档提供了大量技术细节和参考链接，适合深入研究和实际项目开发。文档强调了英特尔在传感器融合领域的技术优势和解决方案，并指出了未来的研究方向和发展趋势。

2025-04-25

【Linux内存管理】统一页面热度信息源：内存管理对齐会议提案与kpromoted设计探讨文档的主要内容

内容概要：本文档讨论了Linux内存管理（MM）系统中统一页面热度信息源的问题。主要介绍了不同来源的页面访问信息（如NUMA提示故障、folio_mark_accessed()、PTE访问位、硬件提示、设备提示等），并详细列出了这些信息源的数据特性（物理地址PA、虚拟地址VA、访问时间Time、节点ID NID）。此外，文档还探讨了kpromoted子系统的功能，它作为单一页面热度信息聚合点，负责从多个来源收集和报告热页访问情况，并维护热页列表。最后，文档提到了当前的工作进展和未来的发展方向，包括将迁移操作分离为独立的异步线程、整合到DAMON以及对区域抽象的关注。适合人群：熟悉Linux内核和内存管理系统，尤其是对页面热度管理和NUMA架构有一定了解的技术人员。使用场景及目标：①理解Linux内核中不同类型页面访问信息的作用及其数据特征；②学习kpromoted子系统的设计理念与实现机制；③探讨如何改进现有系统以提高热页检测和迁移效率。其他说明：此文档基于2025年4月16日的Linux MM Alignment会议内容整理而成，旨在促进社区成员之间的技术交流和技术方案的优化。文档中的信息仅供参考，具体实现可能会随着内核版本的变化而调整。

2025-04-24

SPR TCO Analysis Report

内容概要：本文档《SPR TCO Analysis Report Out v4.1.pdf》详细分析了英特尔（Intel）的SPR（Sapphire Rapids）解决方案与英伟达（NVIDIA）A10/A30显卡在视频结构化服务器市场中的TCO（总拥有成本）。报告首先介绍了背景和目的，指出英特尔目前在边缘AI推理市场和视频结构化服务器市场缺乏有竞争力的解决方案。随后，文档对不同工作负载条件下的性能和成本进行了详细对比，包括轻量级和重量级AI计算任务、H.264和H.265编解码支持等。通过多组实验数据，文档展示了SPR解决方案在低密度产品和轻量级AI工作负载（如H.264 <500G、H.265 <300G）上具有一定的成本优势，但在高密度和重量级AI工作负载下，SPR解决方案的成本明显高于竞争对手。此外，报告还指出了SPR解决方案的局限性，如有限的AI能力、缺少硬件编解码器以及较高的CPU价格。适用人群：对视频结构化服务器市场感兴趣的IT专业人士、系统架构师、技术经理及决策者。使用场景及目标：①评估英特尔SPR解决方案与英伟达A10/A30显卡在不同AI工作负载下的性能和成本差异；②为选择合适的硬件平台提供参考依据；③

2025-04-10

【网络时间同步技术】IEEE1588v2与SyncE时钟同步机制详解：频率与时相同步方案及其应用对比

内容概要：本文详细介绍了IEEE 1588v2时间同步方案和同步以太网(SyncE)的技术原理。IEEE 1588v2旨在满足测量与控制系统对时钟同步的需求，通过Leader-Follower架构实现频率和时间同步，包括Syntonization（频率同步）和Delay Request-Response机制（延迟请求响应机制），可实现纳秒级的时间和频率同步。文档还介绍了不同类型的设备如Grand Master Clock (GMC)、Ordinary Clock (OC)、Boundary Clock (BC) 和 Transparent Clock (TC)，并解释了它们的工作原理。SyncE则通过物理层传输主参考时钟(PRC)的频率，不依赖数据包传输，而是通过物理信号边缘进行频率同步。SyncE需要特定的PHY硬件支持，而IEEE 1588v2可以几乎在任何适配器上运行。; 适合人群：具备通信网络基础知识，对时钟同步技术感兴趣的工程师和技术人员。; 使用场景及目标：①理解IEEE 1588v2和SyncE的工作原理及其应用场景；②掌握不同类型时钟设备的功能和工作机制；③比较IEEE 1588v2和SyncE在频率和相位同步方面的差异；④了解如何选择适合的同步技术以满足特定网络需求。; 阅读建议：本文涉及较多技术细节，建议读者结合实际应用场景来理解两种同步技术的优缺点，并关注各自的技术实现方式。对于IEEE 1588v2，重点在于理解各个消息的作用和同步机制；对于SyncE，则需了解其对硬件的要求及其实现频率同步的方式。

2025-04-10

【云计算与终端管理】Ultra Cloud Client (UCC) 技术架构与产品介绍：多场景高效计算客户端管理方案设计

内容概要：本文介绍了英特尔Ultra Cloud Client (UCC) 技术和产品的架构与特性。UCC旨在解决传统客户端管理中的痛点，如软件问题频发、管理不便等问题。它提供了一种融合解决方案，支持多种客户端模式（TCI、IDV）并允许在两者间切换。UCC系统由三个主要部分组成：预启动引导控制器、运行时操作系统模块和服务端的TC服务。引导控制器负责初始化、认证及镜像部署；运行时模块包括虚拟存储驱动和管理代理；服务器端处理用户、设备管理和访问控制等功能。此外，UCC还提供了灵活的启动方式（内置硬盘、PXE、USB），并通过增量更新机制优化了部署效率。; 适合人群：IT管理员、企业级客户技术支持人员以及对云计算和虚拟化技术感兴趣的开发者。; 使用场景及目标：①适用于教育、银行、企业办公和医疗等行业，用于集中管理和维护大量计算客户端；②确保客户端具备本地性能的同时提高可管理性；③通过安全认证机制保障数据安全，减少因网络依赖带来的性能瓶颈和额外硬件成本。; 其他说明：UCC 2.0版本实现了不同类型客户端的统一管理，支持多种操作系统（Windows、Linux等），并且引入了基于快照的回滚功能以应对突发情况如病毒攻击。系统设计中特别强调了安全性，提供了两种不同的安全启动选项供用户选择。

2025-04-10

OpenVINO 2024.1 发布：增强大型语言模型性能与扩展生成式AI支持

内容概要：本文介绍了 OpenVINO 2024.1 版本的新特性及其对生成式AI（GenAI）和大型语言模型（LLM）的支持。新版本引入了多个最先进的预训练模型如 Llama3 和 Phi-3，并优化了 Mixtral、URLNet、Stable Diffusion 1.5、ChatGLM3-6b 和 Qwen-7B 等模型的性能。此外，还增加了对 Falcon-7b-Instruct 的支持，提供了压缩嵌入、INT8 PyTorch 模型微调以及混合量化等功能。部署方面，新增了 NPU 插件预览版，使 JavaScript API 更易访问，并启用了 ARM 处理器上的 FP16 推理。同时，OpenVINO 还集成了 Optimum 工具包，方便将 Hugging Face 模型转换为 OpenVINO 格式并进行量化。最后，官方发布了多个新的笔记本示例，涵盖从文本到图像生成、视频搜索到文档问答等多个应用场景。适合人群：从事深度学习、自然语言处理和计算机视觉领域的研究人员和技术开发者。使用场景及目标：适用于需要高效运行生成式AI任务的企业和个人开发者，旨在提升模型推理速度、降

2025-03-30

IPU Redfish服务器实施概述：管理接口与用例解析

内容概要：本文档详细介绍了Intel IPU Redfish服务器的实施计划及其关键特性。首先，文档概述了Redfish服务器相对于RDE的优势，并阐述了IMC Redfish服务器的具体实施方案。IMC Redfish服务器的实施分为三个阶段：第一阶段为支持Redfish协议的基础SDK构建，第二阶段涉及系统硬件和软件信息的获取，第三阶段则关注安全启动和认证。此外，文档还列举了一些具体的使用案例，如IMC镜像更新和ACC镜像更新（从ISO文件更新），并提供了相应的API端点。最后，文档讨论了当前面临的挑战，如内存管理和安全性期望，并提出了下一步的工作方向，确保Redfish解决方案达到生产质量标准。适合人群：对数据中心管理、网络设备配置以及Redfish协议感兴趣的IT专业人员和技术管理人员。使用场景及目标：适用于需要理解和部署基于Redfish协议的IPU管理系统的团队，帮助他们掌握IMC和ACC的更新流程，优化系统性能和安全性。其他说明：文档强调了Redfish服务器在提升系统管理效率方面的作用，并指出了未来改进的方向，如减少重启次数和提供完整的安装工具。

2025-03-29

网络状态网关中96百万精确匹配规则卸载的技术解析与实现

内容概要：本文档详细介绍了针对高负载状态网关（如负载均衡器LB、NAT等）的96百万精确匹配规则卸载解决方案。主要讨论了硬件加速（HW）和软件管理（SW）相结合的方法来满足客户对大规模规则卸载的需求。文中提到，为了支持高达1亿级别的精确规则卸载以及有状态会话卸载，需要解决硬件老化计数器限制等问题。此外，还探讨了通过两阶段镜像采样机制避免不正确的老化删除，并展示了内存重新分配的具体方法及其配置步骤。最后提供了基于P4SDE构建的应用演示，用于验证96百万规则卸载的效果。适合人群：从事网络安全设备开发、维护的技术人员，尤其是关注高性能网络处理和规则卸载优化的专业人士。使用场景及目标：适用于需要处理大量连接请求的状态网关设备制造商和服务提供商，旨在提高系统性能并降低延迟，确保高效稳定的网络通信环境。其他说明：文档中涉及的内容为英特尔内部机密资料，仅供授权人员查阅。同时，文中提及的竞争产品如AMD Pensando DSC200和Nvidia Bluefield3 DPU也在一定程度上支持类似的功能特性。

2025-03-29

基于IPU的Cassandra集群技术验证与优化：苹果公司内部技术培训

内容概要：本文档详细介绍了英特尔为苹果公司构建的基于智能处理单元（IPU）的Cassandra集群的技术验证（PoC）。主要内容涵盖IPU存储用例、已建存储PoC、MEV到MMG400的过渡、苹果构建IPU-Cassandra集群的动机以及PoC开发进展。文档还探讨了硬件配置、软件环境设置、性能调优措施及其成果，特别是针对延迟和吞吐量的优化。此外，文档展示了六节点Cassandra集群的具体架构和测试结果，强调了成本和复杂性的降低。适合人群：对分布式数据库系统、NoSQL数据库、IPU技术感兴趣的IT专业人员和技术管理人员。使用场景及目标：适用于希望了解如何利用IPU提升Cassandra集群性能的企业技术人员。主要目标是展示如何通过IPU减少服务器部署的成本和功耗，同时提高数据处理效率。其他说明：文档中涉及的内容属于机密级别，仅供特定授权人员查阅。文中提到的技术细节和测试结果对于评估IPU在大规模数据中心的应用潜力至关重要。

2025-03-28

英特尔AI网络解决方案：Wildcat Peak与FalconRT技术解析及其应用

内容概要：本文档详细介绍了英特尔针对AI和高性能计算（HPC）推出的网络解决方案，重点在于Wildcat Peak IPU和FalconRT协议。Wildcat Peak是一款专为数据中心设计的基础设施处理单元（IPU），支持多种网络协议如RoCE v2和FalconRT，旨在优化AI集群规模和性能。FalconRT是一种可靠的传输协议，解决了传统RoCE协议中存在的多路径负载均衡、无序包传递等问题，提供了更好的拥塞管理和可靠性。此外，文档还展示了基于Wildcat Peak的软件配置和支持模块，以及与其他硬件（如GPU）的集成方式。适合人群：从事AI、机器学习、深度学习、高性能计算领域的研究人员和技术专家，尤其是对网络架构和数据传输有较高要求的专业人士。使用场景及目标：适用于大规模AI训练和推理任务，特别是在需要高效的数据中心网络通信和高带宽低延迟连接的情况下。主要目标是提高AI模型训练速度，降低通信开销，提升系统整体性能。其他说明：文档中还包括了不同版本的Wildcat Peak产品对比表，帮助用户选择最适合自身需求的产品型号。同时强调了英特尔对未来产品的持续支持和发展方向。

2025-03-27

数据中心Falcon传输协议规范-高效可靠的远程直接内存访问与NVMe命令传输机制

内容概要：本文档详细介绍了Falcon传输协议的规范，旨在为高效的远程直接内存访问（RDMA）操作和NVMe命令提供可靠的数据中心传输支持。协议采用了连接导向、请求-响应的方式，保障了从硬件加速的往返时间测量到快速且精确的数据重传等一系列优化措施。它还包括先进的拥塞控制机制如Swift和保护性负载均衡（PLB），并确保数据包可靠传输以及对多种高并发任务的支持。协议实现了事务子层、数据包传送子层及其相关实体的功能划分，并定义了各层次的数据包格式与行为流程。错误处理方面则涵盖了多种异常情况的解决方法，包括超时恢复和资源回收机制。适用人群：从事数据中心网络架构研究和实践的专业人士、系统开发者以及需要深入了解高级网络传输协议的研究人员。使用场景及目标：适用于数据中心环境下的高速网络环境中，用于提升RDMA读写和NVMe磁盘I/O的效率及可靠性，减少延迟并提高性能。目标是满足大规模AI训练、高性能计算与实时数据分析所需的带宽、低延迟能力。其他说明：文中还提供了具体的实例展示了不同类型的交互过程，例如RDMA读写的完整生命周期，并阐述了一些关键配置参数设置的原则。此外，文档强调了该协议符合开

2025-03-20

Ultra Ethernet Consortium规范介绍与高性能AI网络优化

内容概要：本文主要介绍了Ultra Ethernet Consortium（UEC）提出的下一代超高性能计算(HPC)和人工智能(AI)网络解决方案及其关键技术创新。文中指出，现代AI应用如大型语言模型(GPT系列)以及HPC对集群性能提出了更高需求。为了满足这一挑战，未来基于超乙太网络的新规格将采用包喷射传输、灵活数据报排序和改进型流量控制等机制来提高尾部延迟性能和整个通信系统的稳定度。同时UEC也在研究支持高效远程直接内存访问的新一代协议，确保能更好地利用现成以太网硬件设施的同时还增强了安全性。适合人群：网络架构师、数据中心管理员、高性能运算从业人员及相关科研人员。使用场景及目标：①为构建高效能的深度学习模型训练平台提供理论指导和技术路线；②帮助企业选择最合适的网络技术和优化现有IT基础设施；③推动整个行业内关于大规模分布式系统网络层面上的设计创新。阅读建议：本文档重点在于展示UEC如何解决目前RDMA/RoCE所面临的问题并提出了一套全新的设计理念用于未来AI和HPC环境下的通信效率提升。在阅读时需要注意理解作者对于当前网络瓶颈分析背后的原因以及新设计方案所能带来的具体好处

2025-03-13

InfiniBand架构扩展：内存放置保障技术及应用场景解析

内容概要：本文档作为InfiniBand架构第1卷第1.4版附录，探讨了增强型内存放置操作的新特性，包括FLUSH和ATOMIC WRITE，及其在网络传输中的具体应用。主要介绍了新的运输操作如FLUSH（用于确保特定内存区域的数据可见性和持久性）以及ATOMIC WRITE（用于在远程节点的虚拟地址空间进行原子化写入）。它还解释了FLUSH和ATOMIC WRITE的操作机制，包涵内存权限验证、数据包格式与协议遵从。此外，针对这些新特性的软件接口变化进行了详细的定义。适合人群：适用于从事高性能计算网络开发的技术人员，尤其关注内存一致性及分布式系统数据完整性的人士。使用场景及目标：①为上层应用程序提供更高层次的可靠性保障，在多点通信环境或需要持久化的场景中特别重要；②确保远程直接内存访问（RDMA）操作时对内存位置有明确保证，比如可见性和持久化。对于那些对数据完整性和响应时间敏感的应用非常有价值。其他说明：该扩展规范是可选实施的，旨在减少因额外消息传递协议而导致的延迟并提高系统性能。同时强调了不同运输模式下操作行为的一致性和有序执行。

2025-02-27

OpenVINO 自动设备与推理服务优化及应用场景解析

内容概要：本文深入介绍了 OpenVINO 中自动设备(Auto Device)的概念及其在多硬件平台上自动选择最佳执行设备的能力，减少了开发者手动配置的工作量，并提供了性能改进。Auto Device 不仅支持新硬件平台的自动适配，还确保了向后兼容性。文章详细讲解了其性能优势（如17倍加速）、接口配置方法（如使用简单的性能提示）和服务架构设计，并展示了应用案例和未来功能扩展计划，例如自动批处理和支持动态形状网络等。适用人群：适用于有一定经验的软件开发人员和技术经理，特别是那些从事机器学习、深度学习或边缘计算领域的工程师。对于正在考虑引入智能边缘计算能力的应用开发商(ISVs)，以及需要提高AI模型推理效率的研发团队尤为有用。使用场景及目标：旨在帮助开发者更好地理解和利用OpenVINO中的Auto Device特性来优化模型部署流程，减少开发成本并提升产品竞争力；同时为系统集成商提供一种新的解决方案以满足日益增长的高性能低功耗计算需求。此外，也适合对OpenVINO感兴趣的科研工作者作为参考资料进行研究探索。其他说明：该文章还包括有关TensorFlow和PyTorch版

2025-01-29

OpenVINO 自动设备与推理服务优化及应用场景解析

2025-01-29

OpenVINO与百度PaddlePaddle模型优化和性能调优案例研究

内容概要：本文主要探讨了英特尔OpenVINO工具包与百度PaddlePaddle框架之间的合作进展，尤其是针对模型的转换与优化进行了详细分析，并提供了多个具体应用案例，如PP-YOLO对象检测模型的准确性调试以及PPOCR-rec文字识别模型的性能调试等。文章重点展示了在不同硬件平台上进行模型部署时遇到的问题及其解决方案，特别是通过一系列的实验方法逐步缩小问题范围并最终定位到关键的DCN算子和线程管理问题上。适合人群：从事深度学习、边缘计算、模型优化的研究员和技术开发者，对OpenVINO工具包感兴趣的开发者，熟悉计算机视觉任务（如图像分类、目标检测）的人群。使用场景及目标：适用于想要将已训练好的深度神经网络快速移植至嵌入式系统或服务器上运行的场景；同时也有助于理解和提高相关模型在多种CPU架构下的执行效率。其他说明：该文档包含了大量实操技巧，对于深入理解OpenVINO内部机制非常有帮助。此外还介绍了部分新引入的功能和技术改进措施，在一定程度上反映了最新的发展方向。

2025-01-29

OpenVINO与百度PaddlePaddle模型优化和性能调优案例研究

2025-01-29

Intel IPU固件启动机制与管理详解：深入解析MEVTS Boot过程及应用

内容概要：本文档详细介绍了Intel的智能处理单元（IPU）启动流程及其集成管理复杂体（IMC）、Arm计算复杂体（ACC）和统一扩展固件接口（UEFI）的关键特性与操作方式。它涵盖了不同阶段引导程序的功能以及启动过程中涉及的安全性和管理性能，并提供了对调试方法的理解。文档特别提到了在启动过程中处理BIOS和操作系统间的互动，并探讨了为什么需要UEFI支持。对于开发团队成员而言，在遇到客户问题时掌握这些知识可以加快响应速度，提高解决效率。此外还简述了IPU模型相较于传统架构的优势，并展示了用于跟踪代码执行情况的工具，比如劳特巴赫(Lauterbach)工具。适合人群：对嵌入式系统和网络基础设施感兴趣的硬件工程师、软件开发者和技术维护人员。使用场景及目标：①希望通过深入理解固件加载顺序来提升故障排除技能的专业人士；②希望优化设备安全性和可靠性的开发与运维工作者；③计划参与未来IPU项目的设计与实现的创新技术人员。阅读建议：本资料不仅适用于想要了解更多有关英特尔新推出的IPU系列的技术细节的人士，也可以帮助那些寻找解决现场问题的方法或者有兴趣贡献于相关开源项目的群体更好地准备他们所面临的挑战。文中提及的概念相对复杂，建议先熟悉基本概念如BIOS与UEFI的区别后再进行研读。

2025-01-28

国密SM系列算法在Intel QAT硬件加速与软件优化的应用研究

内容概要：本文主要探讨了中国国家密码标准（如SM2椭圆曲线加密、SM3哈希算法、SM4对称加密）在Intel QuickAssist Technology (QAT) 软硬件上的支持情况及其性能表现。具体涵盖了QAT对SM4-CBC、SM4-GCM和SM4-CCM三种模式的支持，并对比不同包大小下各种方法的速度增益。同时介绍了BabaSSL软件实现方式，比较其与QAT引擎软件（QAT_SW）和QAT硬件（QAT_HW）的不同性能。还讨论了Tengine + BabaSSL在TLS 1.3协议下应用SM算法的情况。此外，提供了详细的测试配置环境与测试工具命令行示例，以便再现测试效果。适合人群：从事网络安全、密码学领域相关工作的技术人员或研究人员，熟悉Linux操作系统并且有基于英特尔平台构建解决方案的经验的人群。使用场景及目标：①提高服务器安全连接效率；②评估和选择最优的安全算法实现方案；③为基于国密算法的产品开发提供技术依据和支持。

2025-01-28

IBTA overview of IBTA

2025-01-26

CES 客户问题管理与Bug流程培训：提升客户满意度和优化缺陷跟踪系统

内容概要：本文档介绍了CES（客户体验支持）团队关于客户问题管理和缺陷处理的详细培训材料。首先强调了Q1季度的目标，即解决80%的客户问题并持续改进Bug管理系统，还展示了Power BI仪表盘用于追踪问题关闭率。接着，详细介绍客户问题管理的关键角色及其职责，如IPS进程推广、问题审核与分配、Bug清理会议主持、跨部门协作、定期进度审查等。此外，文中列出了具体的Bug状态变更规则以及每种状态的最大持续时间，以确保高效解决问题和支持决策。对于新客户和服务请求，则提供了一份路线图以便快速适应。适用人群：主要针对CES内部员工及其他相关人员进行流程规范指导。使用场景及目标：为提高客户服务效率和质量而设立的一系列措施实施指南。通过定义明确的问题分类标准（如缺陷产品）、设定合理的处理周期、建立透明的责任机制，使客户能获得更快捷有效的产品和技术援助。同时，也为未来的自动化更新工具集成提供了初步规划。其他说明：文档还包括一些特定客户的分配列表及联系人信息，用以帮助负责人员更好地跟进各自任务；并且提到有关于未来改进方向的思考，比如自动同步更新从IPS评论到LAN租户的数据等功能。这将有助于减少人工操作失误并加速整个反馈循环的时间表。

2025-01-26

ARM架构下大型匿名Folio(LAF)内存管理机制解析与应用场景讨论

内容概要：本文详细介绍了ARM提出的新型内存管理机制——Large Anon Folio（简称LAF），探讨了它的工作原理和技术特点。相比于传统的4KB页表项映射方式，在发生匿名虚拟地址空间的页面错误时直接分配更大范围（如16KB到64KB）的大尺寸folio进行物理内存映射。这种做法可以减少缺页中断次数以及降低每次操作所涉及的对象数目，从而优化CPU缓存行利用率并提升整体性能表现。此外，文中列举了几种具体的硬件支持情况及其带来的额外好处；同时给出了基于LAF改进后的安卓系统与Chrome浏览器编译时间的实际测试数据。最后，对于当前开发状态给出了一些建议性的思考方向，特别是针对特征名称设定、运行期调节选项的设计、统计报告格式三个方面展开了深入交流。适用人群：有兴趣了解Linux内核层面内存管理机制优化工作的专业人士，尤其是关注于移动设备或服务器平台性能调优的研究者和开发者。使用场景及目标：该研究旨在探索一种更为高效的内存映射方法来应对现代计算环境中不断增长的数据需求。一方面希望能在Android系统上获得更好的响应速度；另一方面也期望为Web应用提供更加流畅的操作体验。其他说明：文中提到的技术正处于社区审议阶段，具体实现在很大程度上取决于相关预提交更改是否能成功合并进主线内核版本。另外关于LAF特性命名方面还需要进一步达成共识，确保最终用户不会感到困惑。同时，文中还提出了几个可能会影响后续开发进展的关键议题等待业内同行们的共同商讨解决。

2025-01-25

操作系统内核对大匿名页的支持进展与挑战：内存管理子系统的优化探讨

内容概要：本文主要讨论了为Linux内核增加大匿名页（large anonymous folios）支持的工作进展与面临的挑战。该特性旨在提升性能，尤其是针对基于64位Arm架构的Android系统和其他内存密集型应用环境。通过将多个物理连续页面合并成较大单元进行管理，减少频繁的页面故障中断次数以及降低每页的操作开销，从而改善系统性能。尽管已经取得了一定成果，但还存在如避免稀疏映射引起的内存浪费等若干未解决的问题需要克服。此外，还需定义合适的接口以便灵活配置是否启用此项新功能。适用人群：对操作系统内存管理和优化有兴趣的技术爱好者、软件工程师，特别是研究或从事于Linux内核开发的相关从业人员。使用场景及目标：本论文提供的技术细节和遇到的实际困难对于想要深入了解内存管理模式变化及其影响的人群非常有用；它可以帮助开发者们评估新的folio机制是否适合他们的应用程序或者平台。最终目的是希望能在未来某个时候使这项技术进入主线版本中成为官方发布的组成部分。其他说明：文中详细记录了多位专家的观点交流过程以及具体的技术讨论要点。值得注意的是，在引入类似特性的过程中必须谨慎行事以防止带来长期负面效应的风险。

2025-01-25

内存管理演进：Linux 内核对匿名内存的大尺寸 Folios 支持及其性能优化

内容概要：本文探讨了 Linux 内核引入大型 Folios（大页）来管理匿名内存的技术进展。Folios 具备动态调整页面大小的能力，从而减少页面错误次数和提升内存访问效率。文中介绍了一项改进内存映射机制的工作，在处理匿名内存时默认分配更大的folios，例如 64 KB，默认情况下无法分配大的folio则退回到较小尺寸。同时讨论了硬件支持，例如 ARM 架构下的连续物理地址映射以及与传统 Huge Pages 类似的 TLB 缓存机制，以此缓解虚拟内存转换过程带来的性能开销，显著改善应用尤其是内核编译性能表现，并降低 TLB 错失率。作者还提到了当前工作面临的挑战与尚未解决的问题，如与现有特性集成的复杂性和多架构支持的需求。适合人群：对 Linux 内核内存管理有兴趣的研究者和技术开发者。使用场景及目标：针对操作系统开发者和研究人员，了解现代操作系统内核中先进的内存管理和优化策略的应用方式，旨在为后续相关研究和技术开发提供理论依据和支持。其他说明：尽管该工作已经展示了一些初步成果并取得了一定程度的认可度，但最终是否能够被正式纳入主线版本仍需要克服一些技术和兼容性的障碍。这将对未来生产环境下的高性能计算平台产生积极影响。

2025-01-25

Linux内核内存管理：支持多尺寸匿名页 Folios 提升性能的技术探讨与应用前景

内容概要：本文讨论了当前Linux内核对匿名页仅能处理两个固定大小的情况（通常是4KB的基础页面大小以及2MB的大页面）。为应对近期CPU对TLB条目合并能力的支持，提高系统性能，在2023年Linux存储、文件系统、内存管理和BPF峰会上，Yu Zhao和Yang Shi提出研究路径转向不同尺寸的匿名页（folios）管理方法。他们认为适中的folio大小可能是最佳选择之一，并强调了此改进带来的好处如降低内部碎片率、保持用户空间透明性和简化TLB条目处理等方面的优势。但与此同时，也面临着诸多挑战，比如分配时机策略的确立、如何优化在高压力情况下的释放效率及解决回收时产生的复杂问题等等。适用人群：从事操作系统层面工作的软件工程师或者专注于底层系统架构研究的学习者和技术专家。使用场景及目标：适用于希望深入了解和掌握Linux操作系统内核中高级别内存分配机制及其未来可能演变方向的专业人士；目标是帮助参与者理解和跟进最新技术发展，探索灵活配置的匿名页在实际应用环境中所能带来的潜在优势和改进之处。其他说明：该会议提出了针对多尺寸folis实现的具体措施和技术路线图，如引入heuristic启发式规则确定何时部署何种规格folis，以及讨论相关统计跟踪指标等问题。此外还提到了几个有待深入研究的方向，如如何处理大型页压缩过程、调整khugepaged以避免与回收代码相冲突等问题。

2025-01-25

2023年Linux内存管理中的folio机制进展与挑战-内存子系统重构现状

内容概要：本文探讨了截至2023年5月17日Linux内核内存管理系统的转换进展，特别是从struct page转向folios的工作。文中强调了不同页大小（如4KB、64KB）对性能的影响，指出当前管理大量小页面的低效性和困难。Matthew Wilcox详细介绍了将传统的单一页表结构拆分为多种专业化结构的努力，以应对这一挑战。此外还提及了一些具体进展点，包括slab分配器转换完毕，以及XFS、AFS、EROF等多个文件系统支持folios。不过，还有诸多任务未完成，例如匿名页的folio化和进一步优化内存分配。文章也回应了几项常见误解，澄清folio并不是锁、脏态追踪或错误检测粒度的决定因素。未来还需致力于多尺寸内存块分配的支持。适合人群：操作系统开发者、内核研究爱好者、有经验的系统管理员。使用场景及目标：理解Linux内核内部对于更大尺寸内存块处理的变化趋势；为未来的编程或维护活动做好准备；评估新特性对未来软件项目的影响；跟踪并参与内核社区的技术讨论和发展方向。其他说明：尽管已经取得了显著成就，但整个转换过程预计还需要约两年时间才能全部完成。

2025-01-25

Linux内核内存管理中的folio机制更新及其对文件系统的影响

内容概要：本文详细介绍了 Linux 内核中内存管理子系统的 folio 项目进展及其对文件系统层的影响。自 2020 年启动以来，folio 作为一种物理上连续页面的表示方式，旨在解决内核中‘页’定义模糊的问题，并通过管理更大的内存块来提高性能和效率。文中讨论了 folio 在读取路径、写入路径、文件系统转换等方面的具体应用与挑战，特别是大 folio 分配策略和与现有接口兼容性问题。Matthew Wilcox 在 2022 年的存储、文件系统及内存管理峰会上强调了 folio 转换的重要性和紧迫性，并指出未来的改进方向。适合人群：Linux 内核开发者、操作系统研究人员和技术爱好者。使用场景及目标：①了解内核最新进展并将其应用于实际开发工作中；②探索如何利用 folio 提升文件系统性能；③评估将现有文件系统迁移至新架构的可能性与复杂度。其他说明：文中还提到一些具体的技术细节如 LRU 列表长度大幅减少（高达千倍）、写放大问题以及去除部分过时的操作（例如 write_begin/write_end），这对于深入研究该领域提供了宝贵的参考。

2025-01-25

Linux 内核 Folio 技术及其对未来文件系统优化的影响探讨

内容概要：本文介绍了 Matthew Wilcox 在 2021 年 Linux Plumbers Conference 上关于 Folio 技术的一次讨论。Folio 是一种用于改进 Linux 文件系统的内存管理方法，旨在提高文件系统 I/O 效率和支持更大页面大小。由于遇到意外反对，Folio 片未被纳入 Linux 5.15 主线。文中提到为支持更大页面，需要将使用缓冲头（buffer heads）的文件系统转换为使用 iomap 或 netfs_lib API，以减少开发者对底层缓存的具体干预。同时指出 iomap 需增加一些新特性，特别是对于加密文件的支持。此外，文中强调了社区合作的重要性，包括代码审查和技术交流。适合人群：对操作系统、文件系统以及内存管理感兴趣的研究人员与开发人员。使用场景及目标：本论文主要针对想要深入了解或参与改进 Linux 内核内存管理机制的人士，尤其是那些希望提高 Linux 文件系统性能并探索 Folio 技术未来方向的专业人士。其目的是促进对当前挑战的理解，并推动相关技术创新与发展。其他说明：尽管面对争议，作者依然认为推进 Folio 和大型页的支持是对未来发展的必要步骤，并号召更多内核开发者加入到这一工作中来。文中还提到几位关键人物的看法，他们均同意这一转变不仅有益于现有系统架构优化，也为后续研究提供了坚实的基础。

2025-01-25

Linux 内核进展：页组管理、多代LRU替换算法及Rust语言支持的技术探讨与实践

内容概要：本文介绍了 Linux 内核近期的重要更新与发展，重点关注三个方面：页组（folios）管理机制优化，引入了大容量页（large folios），有助于提高文件缓存效率；提出并改进了多代最小最近未使用（LRU）页面置换算法（MGLRU），增强了内存管理系统识别和清除低效页面的能力；探索在 Linux 内核开发环境中应用 Rust 编程语言的可能性及其相关技术挑战。针对每一个主题都包含了具体的实施步骤和技术细节讨论。这些变化对未来的性能和稳定性有积极影响。适合人群：适用于所有对操作系统底层实现感兴趣的开发者，特别是关注Linux内核发展的人士。使用场景及目标：主要目的是使读者了解最新的技术革新方向以及它们如何改进操作系统的运行效能。此外，在实践中帮助内核开发者更好地理解和采用新的内存管理和编程特性来解决实际问题。其他说明：文中不仅提到理论层面的知识点，还有大量来自社区成员的意见反馈和未来展望等内容作为补充资料提供给读者进行深入了解。同时附带了一些对于某些特定技术和概念的解释说明，使得初学者也能快速跟上步伐。

2025-01-25

Linux内存管理中folios提案的技术争议与讨论

内容概要：本文详细记录了关于 Linux 内核中新的内存管理概念——'folio' 提案的争议和技术讨论。随着 Linux 5.15 版本发布窗口的临近，Matthew Wilcox 提出了 folio 的 Pull Request。尽管 folio 被认为可以提高性能并优化 API 接口，但这一提议遭到了内存管理系统开发者 Johannes Weiner 和社区其他成员的反对。争论焦点主要集中在 folio 是否会导致更大的内存碎片化以及未来扩展性的问题上。最终，Torvalds 表达了一种中立的态度，既不完全反对也不完全支持，folios 合入主干内核的概率因此大大减小。目前，社区内部仍在探索最佳解决方案。适合人群：Linux 内核开发者、内存管理研究者、操作系统研究人员以及其他对内核内存子系统有兴趣的技术爱好者。使用场景及目标：①帮助理解内存管理技术的发展方向及其实现难点；②促进对不同技术决策的理解，尤其是针对可能对未来内核版本造成的影响。其他说明：文中提及了一些具体的技术细节和争论点，如内存分配机制、API 清晰度以及未来可能遇到的挑战，为读者提供了一个深入了解 Linux 社区决策过程的机会。同时，在正式采纳之前，还需等待进一步的实际效果评估。

2025-01-25

Linux内核开发领域的关键话题探讨：内存管理、任务隔离与并发调度进展及其应用

内容概要：本文主要介绍了Linux内核社区当前关注的三个关键技术话题——内存管理(folios)、任务隔离以及由Google提出的轻量级线程机制(user-managed concurrency groups，简称UMCG)。首先是关于内存管理方面的新概念'folios'，这项工作增加了内存管理的有效性并减少了系统开销，提高了某些应用场景下的性能表现。其次，针对延迟敏感型应用程序的需求，提出了一个改进的任务隔离方案，旨在使这类程序可以在CPU上运行而不受到来自操作系统的中断干扰，进而改善响应时间和确定性的需求。最后则是介绍了一种允许用户空间进程创建多个协作式的协程群的接口设计思想，即用户管理模式下的并发分组（UMCG）。文中还讨论了对于这一机制可能存在的长期支持的问题。适合人群：熟悉或正在学习Linux内核开发的知识工作者、系统管理员或者软件工程师。使用场景及目标：为开发者们提供对最新内核特性和潜在变化的理解，帮助他们在日常工作中评估新技术的可能性和可行性，尤其是在优化硬件资源配置和提高应用程序性能等领域内的项目中起到重要的指引作用。其他说明：由于这三个议题涉及到了不同层面上的操作系统行为调整，故而引起了广泛的兴趣和争论。特别是关于如何正确实现用户空间API的设计原则成为了评审过程中特别注意的重点之一。此外，在整个系列中提到的功能可能会随着后续的讨论继续演变直至最终集成到稳定的内核版本中去。

2025-01-25

Linux NFS服务器转向iomap与folios接口以提升性能与兼容性

内容概要：本文详细介绍了Chuck Lever在Linux存储、文件系统及内存管理峰会上提出的Linux NFS服务器（NFSD）转换为使用iomap和folio接口的讨论，以及这些改进措施的目标。首先明确了目前NFSD面临的性能问题，尤其是读写操作中存在延迟，并强调了当前使用的pipe-splice机制的问题。为了提高NFSD的性能， Chuck提议利用其他主流Linux文件系统支持的先进特性如iomap接口（避免不必要的零填充），以及使用folio数据结构替代现有页级别的缓存单元。除此之外还提及了关于RDMA支持、TLS加密通信、跟踪点增加等方面的现状和发展方向。社区对此项改动有不同意见，尤其是在是否需要原子化处理稀疏读方面。随着ext4等主要底层文件系统的逐渐适配，NFSD项目计划跟随这些更新，在未来全面采纳iomap。同时，在将xdr_buf结构替换为支持更大的连续内存分配单位时，NFSD也需要考虑如何更好地集成新的内存管理模式。适用人群：对分布式文件系统有一定研究背景的技术人员、运维人员或者对操作系统层面优化感兴趣的高级开发工程师。使用场景及目标：本文章旨在探讨Linux NFS服务器性能优化的方向和技术手段选择。对于那些面临高并发、大数据传输的应用来说尤其重要；帮助他们找到减少磁盘访问开销的方式，从而降低响应时间并提升系统整体效率。此外，它也有助于安全专家理解NFSD正在采取的安全强化方法及其实施进度。其他说明：文中提到的一些技术难点和争论点反映出在这个复杂度较高的技术领域内，任何改变都需要谨慎评估潜在风险。因此，尽管有许多预期的好处，但在实际部署前还需经过充分测试验证。标签：Linux内核,NFS,iomap,Folio,高性能计算

2025-01-25

内存管理优化之页合集概念-Linux 内核引入 page folio 技术解析与讨论

内容概要：本文详细探讨了由Matthew Wilcox提出并在Linux内核社区引起广泛讨论的新机制——page folio（页面合集）。为解决传统复合页管理中的指针模糊和性能下降问题，Folio被定义为非尾页的页面结构，确保传入foliol型参量的函数无歧义地处理整张复合同页而非单一尾页，从而提高了内存管理体系的明确定义与效率。通过转换函数接受新的页数据类型，Wilcox期望不仅改善API清晰度还能减少重复调用复合头带来的CPU负担，然而这一提案仍在社区内处于评估阶段。核心贡献者的反馈既有支持也存担忧，具体改动可能会影响文件系统及设备驱动等众多方面，同时伴随着约100次的commit提交，对社区的影响可谓重大。适用人群：Linux内核开发者、操作系统高级用户以及对于计算机底层技术有浓厚兴趣的学习者。使用场景及目标：适用于想要深入了解并优化操作系统的内存管理机制的研究人员或从业者。此外，对改进代码性能和提升内核质量感兴趣的程序员也可以借此了解新的抽象层如何简化代码逻辑，消除不必要的复杂性。其他说明：文中还涉及到了针对新命名的一些争论，包括‘folio’是否合适等问题。尽管名称尚存争议，但可以预见，如果这项变更最终得以采纳，则将显著改变未来Linux版本中的内存处理方式，并且有可能为后续的功能扩展奠定基础。

2025-01-25

InfiniBand架构物理层规范1.5版更新：涵盖新技术标准和改进

内容概要：本文档是关于InfiniBand架构第2卷（物理规格）的修订版本1.5，由InfiniBand贸易协会发布。主要介绍了与之前版本相比的新特性及其对链路传输速度的支持，新增加了如PAM4调制、FEC编码以及NDR速率支持等内容。文档还详细列出了多个硬件接口和支持的电气特性的规定，提供了许多具体的实现细节和技术图表。适合人群：对于研究高性能网络互连解决方案有兴趣的技术人员、系统集成商或研究人员。使用场景及目标：这份技术规范适用于需要理解和实施最新的InfiniBand协议栈硬件接口设计的人士。其目的是帮助开发更高效能、更低延迟的数据中心连接解决方案。其他说明：由于是草案版本，在最终批准前仍可能存在某些修改。同时请注意文中提及的标准可能涉及版权保护和其他限制条件，应用时需谨慎评估。

2025-01-25

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人