The Desktop Assumption That Fails
The standard advice for a Linux machine crashing under memory pressure is to add swap. On a traditional desktop, this works because the CPU and GPU have separate memory pools. The CPU uses system RAM, while the GPU uses dedicated VRAM. If the system runs out of RAM, the kernel moves cold data to the swap partition on the disk. The GPU continues to operate on its dedicated video memory, unaffected by the CPU's memory struggles. This separation allows the system to degrade performance gracefully rather than crashing entirely. The assumption is that swap acts as a safety net for the operating system and applications, buying time for the user to close programs without losing their session.
However, this model breaks down completely on the Steam Deck. The device uses a unified memory architecture where the CPU and GPU share the same 16GB of LPDDR5. There is no dedicated VRAM. When a game allocates memory for textures and shaders, it is drawing from the exact same pool that the operating system and background processes use. If the GPU demands more memory than is available, it is not just the CPU that suffers. The entire system is starved. Adding a swap partition to the NVMe SSD does not create new physical memory. It only creates a slower, larger area to park data that is currently in use. The fundamental constraint remains: the hardware has a fixed amount of fast memory, and the unified design means every byte counts for both compute and graphics.
The Reality of Unified Memory
In a unified system, the kernel must constantly arbitrate memory between the CPU and the GPU. The GPU allocation is not a static block; it is dynamic and often aggressive. Modern games, especially those ported from PC, expect large amounts of video memory. On a desktop, if the GPU runs out of VRAM, it may spill to system RAM, but this is a secondary buffer. On the Deck, there is no secondary buffer. The GPU allocation is the primary allocation. If a game tries to load a high-resolution texture set that exceeds the available physical memory, the kernel must decide what to do with the existing pages.
This is where the out-of-memory killer comes in. It is not simply a case of "not enough space on disk." The kernel monitors the memory pressure and, when it cannot find enough free pages to satisfy a new allocation, it terminates processes to free up RAM. The GPU driver is often a heavy consumer, but it is also a critical component for rendering. If the kernel kills a process to free memory, the game crashes. The issue is not that the swap file is too small; it is that the physical RAM is insufficient to hold the working set of the game and the OS simultaneously. The unified memory model means that the GPU is competing for resources that are already scarce.
Why Zswap Changes the Equation
Many guides suggest enabling or tuning zswap, a kernel feature that compresses pages before writing them to swap. The logic is that compressed data takes up less space, allowing more data to be held in RAM-based cache. This can reduce I/O to the SSD and potentially speed up page faults. On a desktop with ample RAM, zswap can be a significant performance booster. It allows the system to keep more data in a fast, compressed state rather than forcing it to the slower disk. The trade-off is CPU cycles for reduced I/O, which is usually a good deal on a powerful desktop processor.
On the Steam Deck, however, the situation is different. The APU is a 6nm AMD chip with limited power and thermal headroom. Compressing and decompressing pages consumes CPU cycles that the game also needs. If the system is already under memory pressure, the CPU is likely busy handling game logic and physics. Adding the overhead of zswap compression can further strain the CPU, leading to frame drops or input lag. More importantly, zswap does not increase the amount of usable memory. It only changes how the memory is stored. If the physical RAM is full, zswap will eventually evict pages to the backing swap device. At that point, the performance benefit is lost, and the system is back to reading from the SSD. The compression ratio varies by data type, and game data is often not highly compressible, limiting the effectiveness of this technique.
The Misunderstanding of Swap Space
A common misconception is that a larger swap file means more "memory." This is false. Swap is not memory; it is a slow, persistent storage area. The kernel uses swap to store pages that are not currently in use. If a page is in swap, it is not available for immediate use. When the system needs that page again, it must read it back from the swap file, decompress it if it was in zswap, and load it into physical RAM. This process is orders of magnitude slower than accessing RAM. On a Steam Deck, the NVMe SSD is fast, but it is still not RAM. The latency difference is significant, especially for random access patterns common in gaming.
When a game crashes due to out-of-memory, it is because the kernel could not find enough free physical RAM to satisfy an allocation request. Adding more swap does not create free physical RAM. It only provides a larger area to store pages that are already in use. The kernel will still need to free up physical RAM to load the new data. If it cannot do so quickly enough, the out-of-memory killer will terminate a process. The size of the swap file is irrelevant to this process. What matters is the amount of physical RAM available and how efficiently the kernel can manage it. A larger swap file might prevent the system from running out of disk space for swap, but it will not prevent the OOM crash.
What To Change Instead
The correct approach is to manage the physical memory usage, not the swap space. First, reduce the memory footprint of the game. This can be done by lowering texture quality, reducing the resolution, or disabling background processes that consume RAM. These changes reduce the demand on the physical RAM, giving the kernel more room to manage the memory pool. Second, ensure that the system is not running unnecessary services. On SteamOS, some background processes can be disabled or configured to use less memory. This frees up physical RAM for the game and the GPU.
Third, consider using a memory management tool that can monitor and adjust the memory usage of processes. These tools can help identify which processes are consuming the most memory and allow the user to kill them if necessary. This is a manual process, but it can be effective in preventing OOM crashes. Finally, if the game is consistently crashing, it may be that the game is not optimized for the Steam Deck's hardware. In this case, the best solution is to play a different game or wait for a patch that improves memory management. The key is to understand that the constraint is physical RAM, not swap space. Managing the physical memory is the only way to prevent OOM crashes on a unified memory system.