mounter625-优快云博客

原创 The state of guest_memfd

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

2025-04-05 16:49:20 404

原创 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 606

原创 Approaches to reducing TLB pressure

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

2025-04-04 15:43:05 258

原创 The end of tasklets

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

2025-04-02 21:51:40 771

原创 Updates on storage standards

由于从 8 月到 3 月的时间较短，2.2 版本的变化并不多，只有少量的技术提案（TP）和澄清被批准。在报告中，他详细介绍了 NVM Express (NVMe) 标准的变化，并更新了与会者关于 SCSI (T10) 和 ATA (T13) 标准在过去几年中较小的变更。在此过程中，多个命令集规范得到了修订，并新增了两个规范：计算程序命令集以及与之配套的子系统本地内存命令集。在接下来的三年里，发布了多个修订版本（2.0a-2.0e），主要包含“修正和澄清”内容，而没有新增功能。

2025-04-01 23:31:14 928

原创 Memory persistence over kexec

在 2025 年的 Linux 存储、文件系统、内存管理和 BPF 峰会上，Mike Rapoport 主持了一个关于内存管理的会议，讨论了这个问题的一个方面：如何使内存内容在 kexec 交接过程中保持不变，以便新内核可以从旧内核停止的地方继续运行。为了实现这一功能，提出了一个新的子系统，称为 Kexec HandOver（KHO），但 KHO 需要额外的层来实现内存内容的持久化，目前还不完全清楚如何实现这一点。在这些范围之外，它将创建临时区域，供替换的内核在早期分配时使用，而不会覆盖保留的内存内容。

2025-04-01 23:15:26 641

原创 Better CPU vulnerability mitigation configuration

David Kaplan 最近提交了一组补丁，引入了一个统一的命令行选项来控制所有缓解措施，同时简化了漏洞检测、配置和应用的逻辑。Kaplan 的补丁重构了内核的缓解配置逻辑，使其依赖于单一的 mitigations= 命令行选项。no_cross_thread — 不缓解一个运行在 SMT（同时多线程）核心上的程序或虚拟机对其同一物理核心上的其他线程代码的攻击。目前，这些选项仅适用于 x86（和 x86_64）架构，其他架构的维护者仍需提供反馈，以确定各选项应对应哪些缓解措施。

2025-03-31 15:36:23 1022

原创 Chapter 4-18. Troubleshooting Congestion in Fibre Channel Fabrics

信元的剩余量为零而没有发生信元丢失，则表明这是由于拥塞而不是由于比特错误造成的。交换机上的端口监控功能自动发出警报，这些症状就会成为检测拥塞的主动机制。收到这些警报后，接下来的步骤应与下一步解释的相同。一节中解释的拥塞症状，从严重性最高的到严重性最低的依次进行。因此，在拥塞故障排除时，没有必要将罪魁祸首追溯到另一台交换机。是一个边缘端口，它的出口拥塞症状表明所连接的设备是罪魁祸首。的终端设备显然遇到了严重的拥塞，而不是物理链路比特错误。级，严重拥塞）计数器也没有增量。级，中度拥塞）计数器增量的同时，

2025-03-29 16:14:43 639

原创 Chapter 4-17. Troubleshooting Congestion in Fibre Channel Fabrics

本案例研究解释了如何在单交换机结构中找到拥塞的罪魁祸首和受害者。提供的两个此类输出显示了环境中的两个交换机。在调查过程中会发现，这两台交换机属于同一环境，但有不同的。一家大型娱乐公司报告称，他们的存储阵列因结构拥塞而发出警报。关于这些警报具体是如何生成的，没有提供太多细节。是在正常链路初始化期间传输的，因此也可能是链路激活期间的非拥塞问题。重传可能会耗费大量时间，这与慢排空造成的出口拥塞非常相似。所示，在分析第一台交换机的命令输出时，发现该交换机的型号为。如果是这样，请参阅之前的系统日志消息，其中显示。

2025-03-29 16:12:55 1452

原创 MM medley: huge page allocation, page promotion, KSM, and BPF

Linux 内核的内存管理始终是一个不断演进的挑战，开发者需要在性能、碎片化和工作负载适应性之间找到平衡。Weiner 在碎片整理方面的改进，以及 Rao 在热点页面提升上的努力，展示了当前围绕内存利用率优化的持续进展。尽管这些补丁仍处于开发阶段，但它们代表了重要的前进方向。如果最终被合并到主线内核，它们将有助于提升从云计算到高性能计算（HPC）等多种工作负载的内存利用效率。不过，为了确保这些改进在真实环境中的有效性，还需要广泛的测试和社区反馈。

2025-03-28 17:07:22 866

原创 Support for atomic block writes in 6.13

在该方法中，数据库首先将旧数据的副本写入磁盘上的临时存储区域，并确保操作成功完成后，才将数据写入实际的磁盘表。需要注意的是，ext4 不支持大于系统页大小（page size）的文件系统块大小，因此在页大小为 4KB 的系统（如 x86）上，ext4 无法使用 16KB 的块大小，也无法支持该大小的原子写入操作。然而，仅仅通过代码审计确认内核不会拆分写入请求，并声称支持原子写入是一回事，而真正将原子写入支持与一个明确定义的用户接口相结合，以确保原子性，则是另一回事。目前，原子写入功能仅支持单个文件系统块。

2025-03-27 21:11:30 782

原创 Guard pages for file-backed memory

不过，Stoakes 指出，这一般不会成为问题，因为进程很少会先映射文件、插入保护页，然后再试图读取该保护页。在 6.13 版本的内核中，众多新功能之一是“保护页”（guard pages），这是一种安全加固机制，可以高效地向进程的地址空间插入不可访问的页面。此外，如果一个文件被截断（truncate），被删除的部分可能包含保护页，但这些保护页本身仍然会保留。如果在某个内存区域的末尾放置一个不可访问的页面，当运行中的进程尝试读取或写入该页面时，就会触发段错误（segmentation fault）。

2025-03-27 15:08:44 566

原创 The state of the page in 2025

同时，struct folio 中的 page 指针指向底层 page 结构，在内核代码中还有许多类似的类型转换操作，这些都需要修复。关于 folio 的定义，存在两种理解。此外，移除 struct folio 中 page 成员的使用，以及 lru 页面字段的引用，也将是有意义的改进。Wilcox 介绍道，Folio 最初的理念是以更大的块来管理页面，而过去几年的经验表明这种方法是可行的。他解释道，距离去年的会议仅过去了十个月，如果再多两个月——相当于一个完整的开发周期，他本可以完成更多目标。

2025-03-27 00:33:11 1001

原创 The guaranteed contiguous memory allocator

这时，将会从预留的内存区域进行分配，并丢弃已缓存的数据（如果这些数据正好位于被分配的区域内）。因此，在会议召开之前，可能不会有太多的评论。这些补丁本身相对较小，并且不会影响未使用 CMA 的系统，因此，我们或许能看到一个超越内存的应用真正落地——距离这个想法首次提出已经过去 15 年了。然而，保证 CMA 的缺点是，预留的内存只能用于那些可以随时丢弃的数据，这将增加系统其他部分的内存压力。由于 CMA 主要用于特定的设备，而这些设备的内存需求是已知的，因此为特定系统设置合适的预留区域应该是相对简单的。

2025-03-26 19:18:43 914

原创 Smarter IRQ suspension in the networking stack

反之，如果该值设置得过小，超时机制可能会在应用程序仍在处理数据包时触发，这将导致软件中断处理与应用程序的处理并行运行，从而影响性能。在网络速度较慢的时代，这种方式运作良好，但在当前数据中心中却显得不够高效。而 gro_flush_timeout 仅在数据流暂停时才会生效，因此可以设定一个相对较短的值，使得当新的数据到达时，处理可以尽快恢复。此时，内核将恢复旧模式，允许 napi_defer_hard_irqs 设定次数的空轮询，然后启动 gro_flush_timeout 计时，并最终重新启用中断。

2025-03-25 05:15:27 918

原创 Chapter 4-16. Troubleshooting Congestion in Fibre Channel Fabrics

从本质上讲，这条信息表明端口上出现了严重的入口拥塞。很可能是交换机的另一个接口出现了严重的出口拥塞。下一个故障排除步骤应该是找到严重出口拥塞的源头。交换机会记录几条系统消息，用于拥塞故障排除。交换端口由于入口拥塞而没有响应链路重置响应（毫秒后仍无法将这些帧传送到相应的出口端口，则。中列出的接口就是出现严重出口拥塞的接口。交换端口仍有从邻居接收的帧队列，并且在。列中同一日期和时间的接口。信元为零的时间较长。信元重新初始化为双方商定的初始值。交换端口发送了链路重置（的原因可能是它的剩余。信元时，它将通过传输。

2025-03-20 04:42:14 764

原创 Chapter 4-15. Troubleshooting Congestion in Fibre Channel Fabrics

中的所有链接（包括其成本）。这可用于确定从罪魁祸首到受害者（反之亦然）的路由。显示设备所属的区域名称。该命令可用于查找罪魁祸首设备的受害者，反之亦然。显示活动的区域集及其所有成员。该命令可用于查找罪魁祸首设备的受害者。显示终端设备的其他管理信息，如型号、固件和主机名。中的所有交换机，包括距离（本地、邻近或远程）、显示结构中的交换机列表。如前所述，交换机的域。命令则显示连接到本地交换端口的终端设备上对等。端口带内提取这些指标，并在交换机上显示。命令显示本地交换端口的信息，而。下文将显示这些命令的输出结果。

2025-03-20 04:37:26 946

原创 Chapter 4-14. Troubleshooting Congestion in Fibre Channel Fabrics

如果出口接口有足够的缓冲空间容纳帧，中央仲裁器就会向入口接口返回授予，入口接口就会通过内部交换基础设施（交叉条）将帧传输到出口接口。如果出口接口没有足够的缓冲空间容纳帧，则中央仲裁器不会返回授予。同样，如果出口接口仍然没有足够的缓冲空间来容纳帧，中央仲裁器将继续不返回授予。当帧到达出口端口时，会检查帧的时间戳，如果超过了帧丢弃超时值（在。命令表明，入口接口希望向出口接口发送帧，但它没有收到中央仲裁器允许它向出口接口传输的授权。这样，就可以沿着拥塞方向追踪罪魁祸首，找到受害者，并查找有关他们的其他信息。

2025-03-20 04:35:18 1090

原创 Chapter 4-13. Troubleshooting Congestion in Fibre Channel Fabrics

值，必须找到早期（在时间上）的条目，然后将两个计数相减。如果找不到同一接口和统计计数器的早期条目，可能是因为这是特定接口和统计计数器组合的第一个条目，也可能是由于。一旦配置并激活了端口监控器，并至少监控了一个数据率计数器，只要计数器的上升或下降阈值被触及，除了。这可以精确定位链路利用率过高的情况，链路利用率过高可能会导致拥塞。积分为零的持续时间，持续时间长于配置的管理延迟。值得注意的是，当统计计数器递增时，记录的是其当前值，而不仅仅是。交换机上的端口监控功能启用数据吞吐量计数器，这些计数器才会记录在。

2025-03-20 04:30:55 729

原创 Chapter 4-12. Troubleshooting Congestion in Fibre Channel Fabrics

值，必须找到较早的（在时间上）条目，并将两个计数相减。如果没有找到同一接口和错误计数器的早期条目，可能是因为这是特定接口和错误计数器组合的第一个条目，也可能是由于。因此，相同的错误或指示在不同类型的交换机或模块上可能会有所不同。值得注意的是，当错误计数器递增时，记录的是错误计数器的当前值，而不仅仅是。秒检查一次其每个接口的错误计数器，查看是否有适用的错误计数器递增（即使递增。它们可能是一个连续的时间块，也可能是。以下是对拥塞故障诊断有意义的错误统计计数器。信元为零的持续时间的计数器。

2025-03-20 04:29:48 805

翻译 Looking forward to mapcount madness 2025

exclusive。

2025-03-18 17:14:37 24

原创 Chapter 4-11. Troubleshooting Congestion in Fibre Channel Fabrics

是一个带有日期和时间戳的循环日志文件。当添加最新条目时，最旧的条目会被自动覆盖。请注意，清除机载日志命令会清除文件和文件中的数据，而清除统计命令只会清除文件中的数据。有几种事件类型，每种类型都有自己固定大小的循环文件。一旦文件填满，按时间顺序排列的最旧条目就会被最新条目覆盖。时），必须有人主动调查各种指示和计数器，才能知道它们是否在主动递增。交换机上的一项功能，用于存储带有时间和日期戳记的重要指标和日志。终结了这一切，因为所有重要的拥塞迹象都有日期和时间戳。日，而已知问题开始于前一天，则可以在命令中加入。

2025-03-16 19:16:52 789

原创 Chapter 4-10. Troubleshooting Congestion in Fibre Channel Fabrics

它能快速显示链路上出现的任何问题。对于端口通道（链路聚合）接口，该命令显示所有成员接口计数器的总和。对于拥塞故障诊断，最重要的计数器集中在拥塞统计部分，但链路统计组中列出的。）命令中的计数器数量更多。这些计数器提供了接口的累积视图，但除了。使用该命令可实时调查正在发生的问题。轴显示的是发出命令前的秒数。当前的秒数（发出命令的时间）在左边。使用此命令可实时调查正在发生的拥塞问题。时间外，并不准确显示其递增时间。每列显示一分钟内累计的。每列显示一小时内累计的。每列显示一秒内的累计。秒前，这一秒内的累计。

2025-03-16 19:13:48 683

原创 Chapter 4-9. Troubleshooting Congestion in Fibre Channel Fabrics

切记不要只启用警报，重要的是要使用它们，并确保这些警报成为工作流程的一部分。我们经常在生产环境中遇到这样的情况：警报已启用，但没人知道它们去了哪里。如果警报没有生成通知（如电子邮件），它们就无法得到应有的关注。例如，当交换机产生信用损失时，主机会同时发出警报，这与问题的起因和结果密切相关。）可通过拓扑显示端到端的流量路径、集中监控拥塞指标、多个交换机生成的警报等，从而极大地帮助排除拥塞故障。最有用的命令是那些对各种指示进行时间和日期标记的命令。交换机具有端口监控功能，可对拥塞症状发出警报，详见第。

2025-03-08 23:54:16 1072

原创 Chapter 4-8. Troubleshooting Congestion in Fibre Channel Fabrics

在交换机和终端设备之间实现时间同步，可将一台设备上的各种指示与另一台设备上的指示联系起来。这是因为在调查拥塞问题之前，不可能事先确定拥塞的来源和原因，甚至不可能确定所有受害者。根据我们的经验，在多交换机环境中，超时掉线可能不会记录在通往罪魁祸首设备的整个路径上，而主要记录在离流量源（受害者）较近而离罪魁祸首较远的交换机上。是一条单独的命令，它将排除拥塞故障通常所需的所有其他命令汇总到一个输出中。在数据路径中，距离故障设备较近的交换端口超时丢弃的情况和数量会减少。命令的输出有助于保存过去的拥塞事件。

2025-03-08 23:52:29 956

原创 Chapter 4-7. Troubleshooting Congestion in Fibre Channel Fabrics

与其他板载显示日志命令一样，输出结果带有日期和时间戳，并按模块显示（在主任级交换机上）。百分比越大，事件发生时间越长（阈值上升和下降之间的时间），影响就越严重。同样，如果端口监控器处于活动状态，且。类型的丢帧原因，如超时丢帧、脱机丢帧（帧击中了刚脱机的端口）和无效。错误统计中查找各种原因造成的丢帧。另一个需要注意的地方是，如果端口监控器处于活动状态，并且。另一个需要注意的地方是，如果端口监控器处于活动状态，并且。百分比越大，影响越严重。计数器受到监控，通常会出现。计数器受到监控，通常会出现。

2025-03-03 15:09:19 1139

原创 Chapter 4-6. Troubleshooting Congestion in Fibre Channel Fabrics

在现有端口通道上增加额外链接，甚至增加一个额外的等带宽端口通道。任何一种方法都能增加交换机之间的容量，消除高百分比利用率。因此，在初步调查问题时，首先要查找这些较高、较严重的拥塞级别，然后再查找较低级别中不太严重的迹象。同样的方法也适用，即所有端口通道成员都应显示类似的拥塞指示。的使用率很高，那么补救措施很简单：增加交换机之间的容量。），则继续查找该交换机上的拥塞，并重复上述步骤。从一个交换机追逐到另一个交换机，一旦到达边缘交换机，检测到）的端口，这表明是由于过度利用造成的拥塞。这是因为，如前所述，

2025-03-03 14:54:25 676

原创 Chapter 4-5. Troubleshooting Congestion in Fibre Channel Fabrics

如果问题仅出现在端口通道的单个成员上，那么可能是其他原因造成的，如物理错误而非拥塞。在这种情况下，需要找到通过正在调查的交换端口进行通信的终端设备或交换端口。如前所述，一旦发现有出口拥塞症状的端口，就可以使用稍后解释的详细工作流程追查罪魁祸首。交换端口上的出口拥塞症状表明该端口处于拥塞路径中。）上的出口拥塞症状来发现，这些端口正在接收来自被调查交换端口（如交换端口。查找与该交换端口通信的设备，并继续调查，以发现出口或入口拥塞的症状（图。下一种可能是，开始调查的交换端口出现了入口拥塞症状。

2025-02-23 05:15:51 848

原创 Chapter 4-4. Troubleshooting Congestion in Fibre Channel Fabrics

有时，这意味着要在与故障相连的交换端口上输入此工作流程，从而直接找到拥塞的源头。它可能是连接到罪犯的交换机，也可能是介于两者之间的交换机，甚至可能是受害者。第三个关键点是，当拥塞在无损网络中蔓延时，一个罪魁祸首可能会使许多终端设备受害，而这些受害设备的用户也可能会报告性能下降。但是，这些方法首先需要以被动方法为基础，而被动方法可以通过故障排除工作流程来实现，本节将对此进行说明，并在后面的案例研究中进行演示。在大多数情况下，自然是从产生警报的交换端口或连接到报告问题的终端设备的交换端口开始调查。

2025-02-23 05:13:11 580

原创 Chapter 4-2. Troubleshooting Congestion in Fibre Channel Fabrics

这些设备就是受害者，它们可能会报告与罪魁祸首设备相同的性能下降。级，因为即使是一次信用损失恢复（链路重置初始）也是一个严重问题。但是，如果在一定时间内出现多次信用损失恢复，则应视为更严重的问题。一旦知道了拥塞的来源和原因，就可以详细调查造成拥塞的终端设备。通常，可通过查看分区数据库来了解与故障设备通信的设备。调查和故障排除的主要目的是确定是否存在拥塞、拥塞源和拥塞原因。直接连接到同路径受害终端设备的交换端口通常会出现入口拥塞症状。直接连接到直接受害终端设备的交换端口通常会出现入口拥塞症状。

2025-02-16 01:14:05 797

原创 Chapter 4-3. Troubleshooting Congestion in Fibre Channel Fabrics

例如，如果一台主机是罪魁祸首，那么与这台主机通信的所有目标都是直接受害者。通过拥塞的网络路径进行传输的终端设备是同路径受害者。与这些终端设备（直接或同路受害者）通信的设备可能是间接受害者。级）的问题，是因为更严重的问题对网络的影响更大，甚至会导致大面积故障。也就是说，先从最高严重级别开始，如果没有发现该严重级别的迹象，再继续下一个较低的严重级别。但与直接受害者不同的是，同路径受害者不会向罪魁祸首发送流量。边缘交换端口症状上的这些差异有助于将连接的终端设备识别为罪魁祸首、受害者和受害者类型。

2025-02-16 01:11:28 974

原创 Chapter 4-1. Troubleshooting Congestion in Fibre Channel Fabrics

它只是我们（本书作者）多年来用来区分最严重的拥塞迹象和不太严重的拥塞迹象的一个值。如果应用程序对拥塞的容忍度较低，则可以使用较低的值，如。请注意，造成丢帧的原因有很多，其中只有部分与拥塞有关。这两种情况都会导致拥塞扩散，造成接收上游设备流量的入口端口拥塞，并从该交换机的拥塞端口发送出去，而上游设备的发送端口则出现出口拥塞。既要注意因拥塞造成的丢帧，也要注意所有其他原因，如。在轻度拥塞期间，帧在交换机中的缓冲时间长于典型的端口到端口交换延迟，从而增加了。级，因为在存储网络中，即使丢帧也是一个问题。

2025-02-06 19:48:08 753

原创 Chapter 3-21. Detecting Congestion in Fibre Channel Fabrics

虽然峰值可以捕捉到所有事件，但有些用户并不希望峰值发出警报，尤其是当这些事件已经被调查时。其他用户更愿意保留峰值利用率事件供自己调查，而在向上级管理部门报告时，他们更愿意使用平均利用率。我们建议同时启用所有这些功能，并在典型的拥塞检测和故障排除工作流程中使用它们。因此，峰值利用率图和平均利用率图完全相同，都会生成相同的警报。虽然数据点相同，但使用峰值函数创建的聚合结果与使用平均函数创建的聚合结果不同。如果交换机上的警报无人关注，那么发送这些警报的价值就微乎其微了。交换机拥塞的最佳实践和我们的建议。

2025-02-06 19:45:57 1250

原创 Chapter 3-20. Detecting Congestion in Fibre Channel Fabrics

在网络设备上进行本地计算时，间隔时间较短，而在远程监控平台上，间隔时间较长。第二点是平均利用率和峰值利用率，适用于所有类型的网络端口（光纤通道或以太网）。在无损网络中监控流量的一个关键考虑因素是，出于所有实际目的，应将出现的充分利用或高利用率等同于过度利用。这是因为，根据我们的经验，大多数满使用率和高使用率情况也会显示一定时间的过度使用。这一问题在定制开发的远程监控平台、应用程序或脚本中更为根深蒂固，因为它们的开发人员可能并不了解光纤通道的这些复杂性。的利用率，这是不准确的，会错误地降低问题的严重性。

2025-01-30 14:03:04 1294

原创 Chapter 3-19. Detecting Congestion in Fibre Channel Fabrics

在监控端口较少的情况下，只要上一次轮询在下一次轮询开始前完成，轮询间隔就可以进一步缩短。）会从交换机中提取指标，而流遥测则会以配置的时间间隔将指标从交换机推送到配置的目的地。它需要一个定制开发的接收器来接收来自交换机的指标，而大多数用户可能无法开发这种接收器。除其他属性外，请注意最小导出间隔，在本文撰写时，流式遥测的最小导出间隔不能低于。虽然从技术上讲，流式遥测优于前面介绍的其他导出机制，但在操作上存在以下挑战。会话解析命令行输出。），因为它们快速、易用、被广泛采用，而且只需在交换机上进行单线配置。

2025-01-30 14:00:23 711

原创 Chapter 3-18. Detecting Congestion in Fibre Channel Fabrics

会话，运行命令，收集其输出并进行解析，以捕获相关指标。虽然这种方法在生产环境中得到广泛应用，但其用户经常抱怨说，当命令输出发生变化时，解析逻辑就会中断，而试图跟上正在发生的变化需要花费大量精力。例如，您可以在一个仪表板上监控一个站点的所有交换机或一个结构中的所有交换机。相反，它是为那些喜欢根据所要解决的问题定制监控平台的用户而设计的。如前所述，显示高利用率的端口很可能是因过度利用而导致拥塞的端口。在相同的演示中，来自连接主机上应用层的指标也会并排显示，尽管。所示，您可以并排关联交换端口上的多个指标。

2025-01-25 07:40:22 1291

原创 Chapter 3-17. Detecting Congestion in Fibre Channel Fabrics

将鼠标悬停在拓扑中的网络链接或交换机上，可以查看更多详细信息。所示，弹出了该接口的拥塞指标图表。单击图表下方的图例可隐藏或显示该指标的图表。例如，当主机连接的交换端口报告拥塞时，主机的健康状况也会受到监控。远程监控平台可同时监控多个网络中的所有端口，提供单一视角的可视性。它会生成彩色编码拓扑图，显示发现拥塞的位置。交换机上端口监控器生成的警报，可以发送到相同的监控平台。排列，并可进行排序，使值最高的接口显示在顶部。选择正在收集的任务或较早完成的任务，即可查看结果。的最新版本中，它的外观可能会有所不同。

2025-01-25 07:38:44 957

原创 Chapter 3-16. Detecting Congestion in Fibre Channel Fabrics

它的设计粒度更大，因此能检测到较短的高入口利用率突发。该计数器可以在较小的一秒间隔内检测上游邻居端口的潜在过度使用情况，而不依赖于平均。计数器类似，但它的设计更加精细，因此能检测到较短的高出口利用率突发。该计数器可以检测较小的一秒间隔内的过度使用，而不依赖于整个轮询间隔内的平均。当内部计数器的计数等于或超过上升阈值时，端口监控器就会触发上升阈值警报。的真正用途是，如果上游相邻端口不支持自动警报，则代表该设备自动发出警报。但是，如果不配置端口监控器，就不会生成自动警报，也不会通知用户。检测过度使用的能力。

2025-01-22 16:16:52 1221

原创 Chapter 3-15. Detecting Congestion in Fibre Channel Fabrics

它被配置为轮询间隔内的计数。的上升阈值的原因，因为当接口在短时间内达到高出口利用率时，就会出现因过度利用而导致的拥塞。信元为零的持续时间，只有长于配置的管理延迟的持续时间才会被捕获。对于诊断可能影响对延迟敏感的应用程序的相对较小的拥塞问题非常有用。它被配置为轮询间隔内的计数。计数器可在交换端口的出口利用率达到配置百分比时进行检测。型计数器，其工作原理是计算轮询间隔内传输的字节数，将其转换为比特。计数器的一个重要特点是，当达到上升和下降阈值时，的下降阈值，以提供更好的诊断信息，说明端口何时以。

2025-01-22 16:14:40 1125

原创 Chapter 3-14. Detecting Congestion in Fibre Channel Fabrics

是因过度使用而造成拥塞的源头，也不适合对其进行翻转或错误禁用，因为这样做只会使其他运行链路上的拥塞更严重。但是，如果边缘端口和核心端口需要不同的值，则应配置和激活两个单独的策略。这些计数器与本章之前解释过的计数器相同。破坏帧），逻辑类型核心端口可以接受翻转和错误禁用的端口防护措施，但不能接受与拥塞有关的计数器。对它们发出警报的概念与本节所解释的相同，但这里不对这些计数器进行解释。计数器取计数器当前值与计数器先前值之间的差值。为触发下降阈值事件，计数器必须下降到的值。计数器必须达到的触发上升阈值事件的值。

2025-01-18 01:38:20 1108

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）操作时对内存位置有明确保证，比如可见性和持久化。对于那些对数据完整性和响应时间敏感的应用非常有价值。其他说明：该扩展规范是可选实施的，旨在减少因额外消息传递协议而导致的延迟并提高系统性能。同时强调了不同运输模式下操作行为的一致性和有序执行。

内容概要：本文主要探讨了中国国家密码标准（如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

内容概要：本文介绍了由InfiniBand贸易协会（IBTA）维护和发展的一种开放标准、非专有的输入/输出互连架构——InfiniBand技术。它详细讲述了IBTA的组织构成，成员权益与义务、技术特点及优势如高带宽低延迟、单链路承载多类型通信流量的能力、以及其广泛的应用范围从两节点互联到数千节点的大规模集群计算环境之中。文中同时提到了多个数据传输速率版本的发展历程和技术路线图，展示了对未来性能增长的规划，预计在未来能够达到近1000Gbps的数据交换能力。适用人群：对高性能网络架构、数据中心基础设施感兴趣的专业人士或研究者。使用场景及目标：本资料可以用来了解最新IT行业发展动向、探索下一代高效能计算与存储系统构建方案的设计思路，同时也为计划采用相关技术的企业提供参考资料。其他说明：该协会每年春秋举行两次插接测试活动，在活动中进行的新品兼容性和合规检查对于确保业界产品的质量和互通性起到至关重要的作用。

2025-01-18

InfiniBand高速IO技术及其在数据中心和高性能计算中的应用

内容概要：本文介绍了InfiniBand (一种高速I/O互连技术) 在行业内的发展现状与技术优势。文章详细阐述了这种由行业协会主导、众多知名企业参与推动的技术是如何通过提供极高的带宽（最高达56Gb/s）、低延迟(<1μs)，高效率以及对远程直接内存访问的支持等方式提高系统性能；减少硬件设备消耗，优化能源利用。此外还强调了其丰富的软件生态系统的成长性，并提到市场对该技术的需求日益增加特别是在云计算，Web服务、金融交易、大数据分析等领域。适合人群：从事IT基础设施规划部署、网络管理员、数据中心架构师以及关注高性能计算领域的专业技术人员。使用场景及目标：适用于需要构建高效能集群或服务器间互联解决方案的数据中心；对于希望降低总体拥有成本、提升业务灵活性和服务响应速度的企业有重要的指导意义。其他说明：文中还引用了行业专家的观点来论证InfiniBand相对于其他同类产品的优越之处，表明在未来几年它将继续保持快速的增长势头并成为下一代数据中心架构不可或缺的一部分。

2025-01-18

空空如也

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

TA关注的人