What Virtual Memory Actually Is
Virtual memory is the operating system's way of pretending your computer has more RAM than it physically does. It does this by moving data between your actual memory and storage. When RAM fills up, inactive pages get written to disk and are brought back when something needs them. Simple in theory. Messy in practice. A swap space is a dedicated partition on your disk set aside for this purpose. A swap file is just a regular file configured to do the same thing. Linux supports both. Historically, swap partitions were the standard because they were faster and less fragmented. These days, swap files work fine on most setups, especially on SSDs, but there are caveats. The kernel manages both through the same mechanism. When you create a swap file or partition and run the appropriate setup command, the kernel treats them identically during page replacement operations. The difference is purely at the filesystem level before activation.
The Linux memory manager divides physical RAM into fixed-size pages, usually 4KB each. Each page has a state: active, inactive, free, or swapped out. The kernel maintains a list called the LRU, or least recently used list, split into active and inactive queues. When memory pressure builds, pages migrate from the active queue to the inactive queue, and eventually get written to swap if they remain idle long enough. There are two main triggers. One is direct compaction failure, which happens when the kernel can't reclaim enough pages through normal cleaning. The other is the kswapd kernel thread, a background daemon that wakes up periodically to drain inactive pages to disk before pressure becomes critical. kswapd is usually more efficient because it acts proactively rather than reactively. The swappiness parameter controls how aggressively the kernel moves pages to swap. It ranges from 0 to 200 on modern systems. A value of 1 means only swap when absolutely forced. A value of 60 is the default on most distributions. Setting it to 0 doesn't disable swap entirely, which is a common misconception. The kernel still swaps under extreme memory pressure regardless of this setting.
Creating Swap Space
Before doing anything, check what you already have with the free command or by looking at swapon output. You need to know whether you have an existing partition, a file, or nothing at all. For a swap partition, you format it first, then enable it. For a swap file, there's an important step most guides skip. You cannot just create a file and start using it. Many filesystems use a feature called CoW, copy-on-write, which means the filesystem may redirect writes to different blocks than expected. This breaks swap because the kernel assumes the data on disk matches what it wrote. On Btrfs, you have to explicitly disable CoW when creating the file. On XFS, you need to set the noalloc range flag. Here is what a typical swap file creation looks like on ext4:
Get the Full Details
Create a sparse file of the desired size without actually allocating disk blocks upfront. Then change its permissions so only root can read it. Format it as swap. Enable it. Add an entry to your filesystem table so it persists across reboots. Verify with the appropriate status command. I used to recommend a swap size equal to your RAM for systems with 8GB or less, and half your RAM for larger systems. That rule is outdated. If you use hibernate, you need swap at least as large as your RAM because the entire memory state gets written to it. Without hibernate, 4GB of swap is plenty for most desktop systems. Nobody needs 32GB of swap on a machine with 64GB of RAM. The kernel won't use it all, and configuring it that way just wastes disk space.
Real Problems I Have Run Into
One specific issue comes up repeatedly. If you create a swap file on a Btrfs subvolume without disabling CoW, the swap will appear to work initially. Pageout operations succeed. But under heavy memory pressure, you get silent data corruption or the kernel throws errors during pagein. I encountered this on a machine where the swap file was created inside a Btrfs subvolume that inherited the filesystem's default CoW setting. The system would hang for 30 seconds or more during memory-intensive operations, and dmesg showed repeated errors about bad swap entries. The fix was to delete the corrupted swap file, recreate it with the proper flags to disable CoW, and reinitialize it. It took about five minutes to diagnose and resolve, but the symptom was vague enough that I spent a day ruling out hardware faults first. Another issue is fragmentation on HDDs. If your disk is heavily fragmented, swap performance degrades noticeably. Each page read or write may require a different seek operation. This matters most on spinning disks. On SSDs, fragmentation has minimal impact because there is no mechanical seek penalty. The difference in swap performance between a fragmented HDD and a fresh one can be anywhere from two to five times slower for page-in operations under load. A third problem people run into is enabling swap on a network-mounted filesystem. Do not do this. The latency alone makes swap nearly unusable, and any network interruption can cause the kernel to lose swap pages permanently. I once saw a system freeze completely because a NFS mount dropped during a memory pressure event, and the kernel tried to read swap pages that were no longer accessible. The machine required a hard reset. Network swap is not supported reliably on any mainstream OS.
Multiple Swap Devices
You can enable multiple swap partitions or files. The kernel balances I/O across them in a round-robin fashion. If you have two swap devices on separate physical disks, this can roughly double your swap throughput. It is one of the few situations where having more swap devices provides a measurable performance benefit rather than just more capacity. To add a second swap file, repeat the creation process and enable it with the same command you used for the first. The kernel will automatically start using both. No special configuration needed. Check the output to confirm both are active.
Tuning Swappiness and Related Settings
Besides swappiness, there are a couple of other parameters worth knowing. The vm.vfs_cache_pressure setting controls how aggressively the kernel reclaims inode and dentry cache. Lowering it slightly can reduce unnecessary swap activity on systems that spend a lot of time working with many small files, because it keeps directory and metadata caches in memory longer. The default is 100. Setting it to 50 is reasonable for desktop systems. The vm.min_free_kbytes parameter sets a minimum amount of free memory the kernel tries to maintain. If you set this too low, the kernel may not have enough buffer before it starts swapping under sudden load spikes. A value of 65536 (64MB) is a safe starting point for systems with 8GB or more RAM. Increasing it further rarely helps and can waste usable memory. I have never seen vm.dirty_ratio or vm.dirty_background_ratio affect swap behavior directly. Those control writeback from the page cache to disk, which is a separate concern. Don't conflate the two. Dirty page writeback and swap pageout are managed by different subsystems even though they both write to disk.
When Swap Is Not the Answer
Swap will not fix an OOM killer situation caused by a memory leak. If an application is continuously allocating memory without freeing it, the kernel will swap aggressively, then start killing processes once it exhausts both RAM and swap. The solution is finding and fixing the leak, not adding more swap. More swap only delays the inevitable and makes the system sluggish during the delay. Similarly, swap will not help if your bottleneck is disk I/O speed. A slow SATA drive will make swap painfully slow regardless of how much of it you configure. If your system spends most of its time waiting on disk, upgrading to an SSD for your swap location is the single most effective improvement you can make. I have seen swap performance improve by four to six times just by moving the swap file from a mechanical drive to a SATA SSD. Container environments are another case where swap behaves unexpectedly. By default, cgroup memory limits do not account for swap usage in the same way. A container can appear to have plenty of available memory while actually pushing hard against its combined memory-and-swap limit, triggering kills that look like random OOM events from outside the container. If you are running workloads inside containers, check the cgroup settings before assuming swap itself is broken.
Monitoring What Is Actually Happening
Use iostat to watch swap-related I/O. Look for consistent write and read activity on your swap device. If you see heavy swap I/O but your system feels responsive, the kernel is likely handling it fine through kswapd. If you see pauses, stutters, or interactivity drops correlated with swap I/O, then you have a real performance problem. The sar command with the -S flag shows historical swap statistics. This is useful for identifying whether swap usage is growing gradually over time, which points to a leak, or spiking during specific workloads, which points to insufficient RAM for that particular task. There is no universal correct swap size. It depends entirely on whether you use hibernate, how much RAM you have, and what kind of workloads you run. Start with something reasonable, monitor actual usage, and adjust from there. Most systems end up using far less swap than they have available, which is exactly how it should work.
