Linux Plumbers Conference 2026 的会议日期为 10 月 5—7 日。本次值得 SRE 关注的内容不只在一个分会场：系统监控、Tracing、Android、eBPF、AI 辅助开发、实时系统和 Live Patching 都讨论了相关问题。会议官网

本文的判断是：这些议题最值得放在一起看的，不是“给现有日志系统接一个 LLM”，而是怎样在有限的观测预算内保留足够证据，把用户症状连接到系统行为，再把诊断结论交给可验证、可控制的修复流程。 这是一种跨议题的综合解读，不是大会已经达成的统一规范。

材料与证据范围：本文依据 2026-10-08 核对的官方议程与议题摘要。文中的实验数字属于作者报告，方案按构想、开发中或已实现分别说明；现场录像与 PDF 正文留待后续深入阅读。排期采用官方议题页与 session 议程。BPF 快照和腾讯 Agentic Network Observability 当前仍显示未排期。

一、议题地图：22 项内容，六条主线

以下时间均为会议当地时间 Europe/Prague，表示官方排期，不表示本文已核验现场是否完整执行或录像是否可用。系统监控议程、Tracing 议程、AI 辅助开发议程、Live Patching 议程与总日程用于交叉核对。

这份地图是按 SRE 关联性筛选的专题索引，不是 LPC 全部相关议题的穷尽清单。

二、主线一：健康度不是“机器没崩”，而是能解释用户和发布结果

2.1 从单点阈值，转向跨发布阶段的可比较性

Meta 的议题把检测、关联和深入定位放进统一的 telemetry 工作流，并强调不同内核发布阶段之间，机器数量、环境及负载差异会干扰健康度比较。官方 session 摘要

对 SRE 的启示：判断版本 A 相对版本 B 是否回归，需要先统一比较条件。实践中应先明确比较人群与条件，例如硬件类型、负载、内核配置、发布批次，再讨论差异。这是本文据议题提出的评估建议；Meta 使用的具体统计模型与上线决策自动化范围仍需详细材料说明。

2.2 内核事件必须连接用户可见结果

小米团队在 Pixel 6、6.18.0-mainline、90 Hz 的指定环境中分析了 40 个 Android 应用，把 lock_contention 与 Perfetto FrameTimeline 关联。作者报告：约 14% 的掉帧可归因于内核锁竞争，且五类热点占锁相关掉帧的 90% 以上，涉及 GPU 驱动、mmap_lock、ZRAM、Binder 分配器和 cgroup 锁。官方摘要

这里最值得迁移的方法是：从用户症状窗口反查关键线程的等待，再定位依赖对象，而不是只统计某类内核事件发生了多少次。 但上述比例属于作者报告的特定实验，不应写成所有 Android 设备的普遍结论；事件在时间上重合后，还需通过干预或复现验证因果关系。

Wattson 的议题则把 Perfetto trace 与按 SoC 建模的 CPU 功耗估计用于内核回归测试。官方摘要它补充了一个容易被忽略的质量维度：响应更快的修改也可能增加功耗。这里的功耗是模型估计，应通过硬件仪器测量校准；GPU、TPU/NPU 属于作者提出的扩展方向。

2.3 长时间测量仍不可替代

OSADL QA Farm 的报告强调长期、跨系统可比较的实时延迟测量，并讨论测试场景随 Linux 和硬件演化而调整。官方摘要

本文判断：这与“模型更强，所以过程数据可以无限削减”的想法构成重要制衡。模型可以帮助解释罕见延迟，但测量窗口、测试负载、硬件差异及尾部分布仍需真实采集。评价长尾风险时，应保留测量时长与负载覆盖范围。

三、主线二：观测预算必须同时计算采集、关联、保存和恢复成本

3.1 大型转储暴露的是诊断经济性问题

CoreWeave 的官方摘要描述了至少 2 TB 内存的典型机器：crash kernel 的内存预留占用客户资源，大转储处理会延长停机；批量同源故障还增加重复采集和分析负担。官方摘要

摘要将几种路线区分为不同状态：

• 开发中：采集前计算故障指纹，识别重复故障；通过 DPU 上的 drgn+sdb 经 RDMA 读取主机内存，探索带外精简转储。
• 构想：先保存故障内存并重启，再做较重的转换和过滤；或按预设数据结构直接采集精简转储。
• 作者标为已实现：将转储、匹配的调试信息、对应版本源码和调查线索放入容器供 AI 分析，并用 agents.md 减少无休止循环。

对 SRE 的启示：比较方案时应同时衡量停机时间、预留内存、存储和分析成本，以及去重或过滤后保留的诊断能力。上述状态来自作者摘要；DPU 方案的生产性能和通用可靠性仍需实验数据支持。

3.2 BPF 快照：把诊断请求变成有界采集

BPF 快照提案以在线内核中的任务、D-state 栈、runqueue、reclaim 和 I/O 状态为对象，探索经过预先约束的内核内遍历与紧凑输出。作者同时把 iterator、helper/kfunc、verifier、输出缓冲和不停机情况下的一致性保证列为讨论问题。官方提案

它提供的是一个值得试验的设计点，而不是“替代所有 tracing”的成品结论。本次检索中该议题仍未排期，也未确认可读的公开性能测量正文。

迁移建议：为每种采集器定义最大对象数、耗时、输出字节数及失败行为。达到限额时应报告 truncated、丢弃计数和有效时间区间，而不是交给分析器一份看起来完整、实际缺项的快照。

3.3 小记录不等于小系统成本

Build ID + offset sampling 比较了直接记录文件身份和偏移，与记录虚拟地址后再依赖映射事件完成符号化的取舍；目标包括讨论混合采样方式。官方摘要

栈记录议题则讨论重复栈挤占缓冲区、栈合并及用户态栈的文件关联问题。官方摘要两者共同提醒我们：压缩单条事件，不一定能减少整套证据系统的开销；关联元数据、映射生命周期和重复记录同样占预算。

本文建议的度量口径 是：

1
2
3
4
5
6
7

观测总成本
= 热路径记录
+ 对象身份与关联维护
+ 栈与符号化元数据
+ 缓冲和持久化
+ 故障时采集扰动
+ 离线分析与误判成本

这不是会议提出的统一公式，而是一个便于比较方案的工程记账方式。

3.4 低扰动工具要能进入真正的故障现场

生产 RT tracepoint 议题提出将抢占／IRQ 开关事件从较重的设施中拆开，通过独立配置与 static key 控制启用。官方摘要perf/ftrace 互通议题则尝试复用同一份采集数据，减少为统计分析和时间线分析重复录制。官方摘要

这些工作的共同价值是降低“只能在实验室开启”的门槛。但补丁提案、已排期演讲、内核已合入和发行版可用，是四个不同状态，应分别记录；实际开销需要在目标负载下测量。

四、主线三：比日志数量更重要的是关联键、生命周期和等待关系

4.1 故障报告应有同一次启动的时间线

统一内核故障报告提案关注 dmesg、syslog、devcoredump 和 sysfs 信息分散、采集延迟及环形缓冲区覆盖。它建议在问题发生时自动采集，并在服务端按 session／boot 关联、匹配已知问题和通知相关维护者；非致命问题可能在稍后级联成更严重故障。官方摘要

对长时间故障的启示：最终 crash log 应与先前关键事件配合，借助时间和身份信息连接故障过程。实际落地还需明确脱敏、用户授权、保留期限，以及跨设备标识是否可被关联；这属于本文补充的部署要求。

4.2 per-skb metadata：身份应跟随被观测对象

Cloudflare 的包路径追踪尝试在 netns、隧道、IPsec 和过滤规则之间保留同一数据包的路径。摘要指出，用外部 BPF map 保存旁路状态需要维护释放清理，而这可能使只关心少量包的采样器仍承担大量包的生命周期事件成本；其上游探索是让 metadata 随 sk_buff 生命周期存在。官方摘要

这比“给每条日志加一个 ID”更深一层：身份的创建、传播、变换和销毁本身就是观测机制的一部分。

映射到设备端，可以借鉴这一问题意识来设计 Binder transaction、异步任务或请求对象的关联信息。不过，复用地址、对象克隆和跨进程身份如何处理，需要根据各子系统的对象语义独立定义。

4.3 从锁顺序，扩展到通用等待／事件依赖

DEPT 关注等待和事件的关系，而不仅是传统锁的获取顺序，覆盖 completion、folio lock、DMA fence 等同步模式。作者把误报及子系统注解不足明确列为推进工作的难点。官方摘要

持锁者无法运行的 fleet 调查也说明，只看等待线程不够，还需要追踪被等待对象及其拥有者的可运行状态。官方 session 摘要

本文判断：这支持构建可解释的等待图，但不支持把任何统计相关图都称为“因果图”。边必须有来源和语义，例如“线程 A 在等事件 E”“任务 B 负责产生 E”；缺少关联或注解时，应保留未知状态，而不是由 LLM 补成确定事实。

五、主线四：AI 改变诊断的入口，但不替代测量与调试工具

5.1 Performance prompts：维护的资产不再只有工具代码

Brendan Gregg 的议题讨论用 prompt、skill 和 agent 组织性能分析，以及它们对 flame graph、eBPF、ftrace、PMC/MSR 等工具的影响；还提出是否应像维护性能工具那样维护诊断提示和技能。官方摘要

值得借鉴的不是“自然语言取代所有命令”，而是把诊断经验写成可版本化的过程：适用问题、所需证据、可执行工具、停止条件和结论格式。这是本文的工程化建议；议题对纳入内核树提出的是讨论问题。

5.2 drgn + MCP：让模型按证据决定下一次查询

drgn-mcp 的摘要描述了将 drgn 调试能力暴露为结构化工具，并计划用真实 RT 内核停滞的 vmcore 演示调查。官方议题页与 session 议程均排在 10 月 6 日 13:00。官方摘要、更新议程

对故障分析工具而言，较有价值的模式是：

1
2
3
4
5

提出根因假设
    → 调用受控调试工具
    → 获取任务、锁或依赖的实际状态
    → 修正假设
    → 列出仍缺少的证据

这条路径比只让模型阅读一段 crash 文本更容易保留证据来源。通用故障集上的诊断准确率，以及幻觉、错误符号和损坏转储等边界，需要专门评测。

5.3 Agentic 网络观测首先是系统工程

腾讯的未排期提案明确把轻量透明的框架、高质量数据和强隔离环境列为引入 AI 推理前的条件。官方提案

本文判断：底层观测系统与通用 Agent 平台在这里的交集，不是无限扩大自主性，而是让模型能够按需取证，同时不让它绕过权限、资源和执行边界。故障诊断默认只读；提高采样强度或执行修复，需要独立的控制路径。这是迁移建议，不是提案中已验证的完整产品规格。

六、主线五：从“发现问题”走向“可复现、值得修、有人负责”

6.1 报告数量不是可靠性成果

What Bugs Matter? 关注异构报告的归并、子系统映射、在 KASAN 内核中尝试生成并运行 reproducer，以及实际影响评估。官方摘要

同一作者的 From Findings to Fixes 进一步介绍正在开发的持续缺陷收集与验证平台，强调验证复现条件、触发权限和实际影响，再为获得运行证据的问题生成分析和候选补丁。官方摘要两场内容相关，不宜当作两份相互独立的效果验证。

对 SRE 的启示：报警、疑似缺陷、可复现问题、值得投入的问题和已完成修复，应是不同的状态。incident 的解决状态应以修复后的实际验证结果为依据。

6.2 Syzbot：自动化的是补丁迭代，不是取消责任主体

Syzbot 介绍了候选补丁先进入审核列表、接收自然语言反馈或审核命令、再决定是否转向公共列表的两阶段流程。作者在摘要中将系统标为 POC，并报告截至 2026 年 9 月已有 30 个 AI 辅助补丁合入上游。官方摘要

这个数字属于作者的阶段性报告，本次没有逐项核对提交记录。比数字更值得学习的是责任边界：AI 可以生成、回答问题和迭代，批准进入上游的审核者仍需承担签署责任。

本文建议的修复状态机 是：

1
2
3
4
5
6
7
8
9

finding
  → evidence collected
  → reproduced / not reproduced / insufficient evidence
  → impact assessed
  → patch proposed
  → regression checked
  → reviewed
  → rolled out
  → outcome verified

其中，reproducer 与构建结果分别记录用例和配置覆盖范围；完整修复还需回归与评审，线上部署按既定授权执行。

七、主线六：观测系统本身也需要可预测的控制与验证

7.1 BPF Runtime Verification：已知规则可变成在线检查

BPF RV 议题探索把确定性自动机等运行时验证逻辑映射到 BPF，利用 maps、ring buffer、struct_ops 等机制与现有 RV 框架和命令行生命周期管理整合。官方摘要

它提示了一条与大型模型互补的路线：规则明确、状态空间可控的问题，可以由专用 monitor 在线判断。“把经验证的故障经验进一步实现为轻量检测器”是本文的延伸，不是该演讲已经证明的自动编译能力。 monitor 的误报、漏报、事件缺失和资源消耗仍需测试。

7.2 Livepatch 与探针冲突不是旁路小问题

共存模型议题指出，热补丁与 ftrace、kprobe、kretprobe、BPF 等机制可能争用同一函数附近的插桩能力，造成发布阻塞或观测缺口。讨论方向包括占用报告、明确的失败原因、转换进度和负向测试。官方摘要

官方议题页与 session 议程均将该讨论排在 10 月 7 日 15:45。更新议程

SRE 含义：telemetry 并非永远安全、可忽略的旁路组件。探针本身会影响权限、时序和发布行为；自动诊断系统在增加探针、增强采样或提出 livepatch 前，应该先了解已有占用和冲突。这是对系统设计的要求，不代表大会已经产出一个稳定的统一 ABI。

八、可以提炼出的五个设计概念

下面是本文依据上述议题归纳的术语，不是宣称 LPC 已形成的新标准。

“证据充分”总是相对于具体问题和验证方法而言。对于未知故障，合理的输出可能是多个候选根因及下一步采集请求，而不是一份高置信、单一答案。

九、对 Android / OpenHarmony 的迁移建议

本节是概念设计，不是 LPC 已经验证的手机端架构，也不假定两个系统提供完全相同的接口。

建议把系统拆成一条较短的闭环：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

低成本症状与状态变化
        ↓
触发式、有预算的证据采集
        ↓
按启动／进程／任务／请求身份组织证据
        ↓
确定性分析器先做时间分解与依赖检查
        ↓
Agent 形成假设，并按需补充取证
        ↓
复现／故障注入／回归验证
        ↓
人工或既定策略批准修复
        ↓
沉淀故障样例、检测规则和诊断技能

9.1 第一版先解决一个问题，而不是追求通用自主运维

较合适的起点是 ANR / AppFreeze 的一种等待类故障：从用户可见超时窗口出发，区分主线程正在运行、可运行但没获得 CPU、等待锁、等待 IPC 或等待 I/O，然后沿实际接口可提供的依赖继续调查。

设备端优先做便宜的检测和有界采集；较重的检索、源码分析和候选修复可以放在隔离的分析环境。不要在设备已经严重卡顿时，默认启动无界扫描或高开销采集。

9.2 Evidence package 至少要说明“它没记录到什么”

下表是建议的数据契约，不是现成内核接口。

对敏感数据还应有明确的脱敏和访问范围。内存、用户标识和业务载荷的采集与上传，应遵循具体授权和数据最小化要求。

9.3 用故障库评价“少记录是否仍然够用”

要验证稀疏记录方案，可以从已知根因、已有修复及可重复触发的故障样例开始，对比不同采集预算下的诊断结果。评价目标不只是正确答案比例，还包括错误高置信结论、需要补采的比例、未知问题的保留能力，以及设备端的 CPU、内存、延迟和电量开销。

这样的试验才能回答：“减少的那些数据，是否真的没有诊断价值？”采集策略的有效性应由这套可重复试验判断。

十、让证据能力与验证范围对应

快照描述状态，回放还需要执行条件。 快照描述某段采集窗口内的状态；完整执行回放还依赖输入、调度、外部状态与非确定性来源。filtered dump、live snapshot、checkpoint 和 deterministic replay 应分别说明能力。

相关线索需要因果验证。 时间线和依赖关系缩小候选范围，结论还要接受反例、复现或干预检验。缺失信息保留为未知，模型推断单独标识。

有界采集需要实际测量。 静态开关、BPF verifier 和遍历限额提供约束，目标工作负载上的测量说明实际扰动，尤其要覆盖极端负载。

自动生成的结果需要独立检查。 诊断脚本、检测规则和补丁分别通过相应验证，观察、测试、修改和部署权限按职责设置。

对于低开销设备观测，可以从少量长期线索、触发式状态采集、依赖关联和按需诊断逐步建立闭环。目标是预算内的诊断充分性：保留有身份、有时间、有范围、能够支持检验的证据，并持续验证观测和修复的实际效果。

原始材料索引与阅读顺序

官方来源清单与链接核验记录涵盖本文引用页面，核验日期为 2026-10-08。

优先从官方 System Monitoring and Observability MC 进入，随后结合 Tracing MC、Android MC、AI 辅助开发 MC、eBPF Track 和 Live Patching MC。其中部分 session 列出了直播入口；是否存在可用回放及每场起止点，本次没有逐一核验。

截至本次核验，官方页面明确列出幻灯片附件的议题包括 Performance Prompts、What Bugs Matter、Android 锁竞争、长期延迟监测、Wattson、Syzbot、From Findings to Fixes 和 BPF RV。这些附件正文留待进一步阅读；后续深化应补充页码、实验条件、代码状态和录像时间点。