The Desktop Myth
Guides telling you to increase swap space on the Steam Deck are applying desktop Linux logic to a handheld with no business using it. On a traditional PC, the CPU and GPU have separate memory pools. When the GPU runs out of video RAM, it can borrow from system RAM via the Unified Memory Architecture, but the CPU still has its own dedicated pool for applications. If the CPU runs out of RAM, it swaps to the hard drive. Adding more swap gives the CPU more room to push data off the active memory, preventing the kernel from killing processes to save the system. This is a valid strategy for a desktop where the storage drive is fast and the memory hierarchy is distinct.
The Steam Deck does not operate this way. It uses a unified memory architecture where the CPU and GPU share the same 16 GB of LPDDR5. There is no separate video RAM pool to overflow into. When a game crashes with an out-of-memory error, it is not because the CPU needs more scratch space on the drive. It is because the total physical memory available to the entire system has been exhausted. Adding swap to the eMMC or NVMe drive does not create new physical memory. It merely creates a slower, secondary parking lot for data that the system can no longer hold in the fast RAM. For a handheld with limited thermal headroom and storage bandwidth, this is the wrong lever to pull.
Compressed Cache Limits
The Steam Deck runs SteamOS, which is based on Arch Linux and includes a feature called zswap. Zswap is a compressed cache that sits between the active RAM and the swap device. When the system is under memory pressure, it compresses pages that are about to be swapped out and stores them in a small, dynamically allocated pool within the remaining RAM. This trades CPU cycles for reduced I/O, which is beneficial because the Deck's storage is slower than the RAM. However, zswap has a hard limit. By default, it can only use a specific percentage of the total system memory for this compressed pool.
This is where the "more swap" advice falls apart completely. If you increase the size of the swap partition, you are not increasing the size of the zswap pool. The zswap pool is capped by the physical RAM available, not the storage capacity. Once the zswap pool is full, any new pages that need to be swapped out must be written directly to the storage device. This causes a massive spike in I/O latency. On a handheld, this latency translates directly to stuttering and frame drops. If the game is already crashing due to memory exhaustion, forcing data onto the slow storage will not save it. It will likely make the crash happen faster because the system is spending more time managing the swap I/O than rendering frames. The bottleneck is not the lack of swap space; it is the lack of physical RAM to hold the compressed cache.
The GPU Allocation Problem
The real cause of out-of-memory crashes on the Steam Deck is usually the GPU allocation. In a unified memory system, the driver must decide how much of the 16 GB to reserve for the GPU and how much to leave for the CPU and system processes. By default, the driver often reserves a large chunk for the GPU, assuming it will be needed for textures and frame buffers. If a game is poorly optimized or if the user has set the GPU allocation too high, the CPU and system processes are left with very little memory to work with. When the system runs out of CPU memory, it starts swapping. But as established, swapping on the Deck is slow and ineffective for real-time gaming.
The fix is not to add more swap, but to reduce the GPU allocation. This frees up more physical RAM for the CPU and system processes, reducing the need to swap in the first place. In SteamOS, you can adjust this by creating a custom environment variable that sets the maximum VRAM the GPU can use. For example, setting the GPU allocation to 6 GB instead of the default 8 GB leaves 10 GB for the CPU and system. This is a direct trade-off. You are giving the GPU less memory, which may cause texture pop-in or lower resolution in some games, but you are giving the system more stability. If a game is crashing due to out-of-memory, it is almost always because the GPU is hogging too much of the shared pool. Reducing the GPU allocation is the only way to actually increase the usable memory for the processes that are causing the crash.
When to Use Swap
There is a specific scenario where increasing swap might help, but it is not the one most people are experiencing. If you are running the Steam Deck in desktop mode and using it for development or heavy multitasking, you might benefit from a larger swap partition. In this context, you are not playing a real-time game, so the latency of swapping is less of an issue. You are running long-running processes that can tolerate slower memory access. In this case, having a larger swap partition can prevent the system from running out of memory entirely, allowing you to keep more applications open. However, this is a niche use case. For the vast majority of Deck owners who are playing games, increasing swap is a waste of time and space. It does not solve the problem of unified memory exhaustion. It merely delays the inevitable by providing a slower place to put data that cannot fit in RAM.
If you are still experiencing crashes after adjusting the GPU allocation, the issue is likely not memory management at all. It could be a driver bug, a game optimization issue, or a hardware problem. In these cases, increasing swap will not help. You need to look at the logs to see what is actually failing. Is the game running out of VRAM? Is the system running out of RAM? Is there a specific error code? Without this information, you are just guessing. The most common mistake is to assume that because a desktop guide says "add swap," it will work on the Deck. It will not. The Deck is a different animal. It has a different memory architecture, a different storage speed, and a different use case. You need to treat it as such. Stop adding swap. Start adjusting your GPU allocation. That is the only change that will actually fix your out-of-memory crashes.