O-RAN 科普教育

Go Runtime × Linux cgroup v2 × GOMAXPROCS Go 1.25 開始加入 container-aware GOMAXPROCS ：在 Linux 上，Runtime 不再只看機器有多少 logical CPUs，也會把 cgroup 的 CPU bandwidth limit 納入預設 parallelism 的計算。直覺上，如果 Linux 將一個程式限制在約 2 CPU 的 throughput，Go 應該也會把預設 GOMAXPROCS 壓到 2。 但我在追查 cgroup 行為時遇到一個反直覺的情況： Linux kernel 確實只讓整棵 subtree 得到約 2 CPU 的平均 throughput，Go 1.25、1.26、1.27 卻都可以在同一棵 hierarchy 的 child 裡得到 GOMAXPROCS=5 。 kernel view: effective CPU throughput ≈ 2 CPUs Go runtime view: runtime.NumCPU() = 5 GOMAXPROCS = 5 問題不在於 Linux 沒有限制成功，也不是 GODEBUG 沒有打開。真正的差異在更底層： Linux 的 CPU bandwidth enforcement 是 hierarchical 的，而目前 Go Runtime 的 cgroup CPU-limit observation 只追蹤 process 所在的 leaf cgroup。 本文核心： 這不是要證明「Go 的 container support 整體是錯的」。Go 1.25 的 container-aware GOMAXPROCS 解決了很實際的 production 問題；本文處理的是它目前一個已知的 observation boundary： visible ancestor 有更嚴格 quota，而 leaf 本身沒有 local limit 時，Kernel 與 Runtime 可能對「有效 CPU throughput」得到不同的答案。 本文會一路追到下面幾層： CPU quota 與 GOMAXPROCS 為什麼不是同一件事 cpu.m...