docs(changelog): Clarify when CpusetMems pinning actually applies

rapsealk · claude · rapsealk · commit 2ac23715b559 · 2026-04-26T00:13:08.000+09:00
The optimization only fires when the CPU allocation fits on a single NUMA
node. Under the default `INTERLEAVED` affinity policy, multi-core
allocations spread across nodes and the change is a no-op. Make this
explicit so operators know to pair the upgrade with `PREFER_SINGLE_NODE`
if they want the latency win for multi-core workloads.

Co-Authored-By: Claude Opus 4.7 (1M context) &lt;noreply@anthropic.com&gt;
diff --git a/changes/11222.enhance.md b/changes/11222.enhance.md
@@ -1 +1 @@
-Pin container memory to the CPU's NUMA node via `CpusetMems` when the allocation is node-local.
+Pin container memory to the CPU's NUMA node via `CpusetMems` when an allocation fits on a single node. Most effective with `affinity_policy=PREFER_SINGLE_NODE`; under the default `INTERLEAVED` policy, multi-core allocations will typically span nodes and fall back to the kernel's default placement.

Original file line number	Diff line number	Diff line change
`@@ -1 +1 @@`
`1`		-Pin container memory to the CPU's NUMA node via `CpusetMems` when the allocation is node-local.
	`1`	+Pin container memory to the CPU's NUMA node via `CpusetMems` when an allocation fits on a single node. Most effective with `affinity_policy=PREFER_SINGLE_NODE`; under the default `INTERLEAVED` policy, multi-core allocations will typically span nodes and fall back to the kernel's default placement.