Repository navigation
ci: 负载下的启动耗时证据 (#81/#144/#40) - #204
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f7ec9d7722
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| workers = [multiprocessing.Process(target=burn, args=(deadline,)) for _ in range(8)] | ||
| for worker in workers: | ||
| worker.start() |
There was a problem hiding this comment.
On the configured Windows runner, multiprocessing uses spawn, so each child imports this script and executes the unguarded worker.start() loop again. All eight children consequently exit with a bootstrapping RuntimeError before reaching burn, while the parent still collects samples and successfully writes a report claiming eight active workers. Reproducing the extracted script locally with the spawn start method produced eight such errors and a zero parent exit status. The reported measurements therefore do not establish startup latency under CPU load. Put orchestration behind an if __name__ == "__main__": guard, verify worker readiness/liveness during sampling, and rerun the evidence before retaining the loaded-run conclusions.
AGENTS.md reference: AGENTS.md:L12-L12
Useful? React with 👍 / 👎.
内容
在同一结果目录补充「本地 CPU 负载下的启动耗时」：新作业
windows-2025-startup-under-load（8 个忙循环并发，测 20 次 PowerShell 5.1 启动），并同步 validation.json。结果（run 40945977134）
对照空闲 p50 0.110 s：负载只把中位数抬到 0.172 s，最慢 1.921 s，仍与 10 秒期限相差一个数量级以上。
结论
本地 CPU 争用同样不能解释 10 秒级停顿——进一步把 #81/#144/#40 的失败推向「宿主级外部停顿」（安全软件扫描、存储阻塞、VM 调度），而不是可通过降低负载规避的争用。
边界
Refs #81 #144 #40