Kubernetes ties node swap's up-to-3x density gain to memory that sits idle

The kernel-build test shows where the density gain stops. Without swap, a Linux 6.1.1 build needed a memory limit of at least 600 MB to avoid an out-of-memory kill ^[3]. With swap on a local SSD, the limit fell to 300 MB and the build finished in 374 seconds against 433 ^[4], roughly 14% faster ^[13]. At 200 MB it ran more than 40% slower, with long I/O waits, because its active working set had been forced into swap ^[5]. A 200 MB limit is one third of the baseline. On memory alone, that is the setting that fits three builds in the RAM one needed without swap ^[12].

The gap between 300 MB and 200 MB comes from what a build keeps in memory. Earlier compiled objects sit inactive while the pipeline moves on, and the linking phase needs a brief, large spike ^[6]. The inactive objects paged out with no cost to run time. Once the limit cut into memory the build was actively using, the I/O waits began ^[4][5]. The post's authors wrote that the result shows "swap serves as an insurance policy for burst memory, not a replacement for active RAM." ^[10]

Agent sandboxes look like the inactive half of that build. The post describes agent pods that need large footprints to start and to run untrusted code, then sit idle for long stretches waiting for user prompts ^[2]. That resident, idle memory is what swap moves to disk. The headline figure, density gains of up to 3x "often with little or no latency cost", is a summary across all three workloads ^[14][15]. The summary does not say which workload reached 3x.

A skeptic would point out that Kubernetes historically discouraged swap, and the post agrees there were reasons. Under cgroup v1, memory and swap shared one combined limit, so a container's real memory use was unpredictable and hard to isolate ^[7]. The GA support relies on cgroup v2, which accounts for swap separately ^[8]. Paging to spinning disks was slow, a penalty the post says fast NVMe local SSDs largely eliminate ^[9]. Both answers are conditions. A node without cgroup v2 or without fast local drives is still subject to the old objections ^[7][9].

In our view, memory budgets can be planned around swap for workloads whose idle share has been measured, with limits kept at or above the active working set. Planning a whole fleet around the 3x ceiling goes further than the evidence. The benchmarks are the project's own, published on its blog ^[11]. The decision this quarter is where to set limits. Next quarter's consequence is how packed nodes behave when more sandboxes are active at once than the plan assumed. For one workload, the post has already measured what active memory in swap costs: a run more than 40% slower ^[5].