Linux swappiness is often described as a percentage of RAM that must be used before swapping begins. That explanation is misleading. It encourages people to choose a number without understanding the trade-off and then judge the result by whether the swap meter looks smaller.

A better approach starts with the workload and the relative cost of reclaiming different kinds of memory. Swappiness is one policy input, not a complete memory-management system. This guide explains its meaning and provides a controlled way to evaluate a change without presenting any single value as the best setting for every laptop, workstation, or server.

Understand what the setting expresses

The Linux kernel's virtual-memory sysctl documentation defines swappiness on a scale from 0 to 200 as a rough relative cost comparison between swap I/O and filesystem paging. At 100, the policy assumes equal costs. Lower values treat swap I/O as more expensive; higher values treat it as cheaper.

The same documentation notes that values above 100 can make sense for some fast or memory-backed swap arrangements. Setting the value to zero is not equivalent to disabling swap entirely. These distinctions matter because a tuning guide based on a simple “RAM fullness percentage” is explaining a different concept from the actual control.

For an introductory view of the resources involved, begin with RAM versus swap. Swappiness makes more sense once you distinguish active application data, file-backed data, swap capacity, and current swap activity.

Define the problem before changing policy

Write a concrete problem statement. “The swap number is not zero” is not enough. “Interactive application switching pauses while the nightly job runs” is more useful. “A batch job completes, but exceeds its allowed processing window” is another measurable problem.

Identify the time interval that matters. A desktop user may care about the delay between clicking a window and using it. A build worker may care about total job duration. A service may care about its slowest routine requests. A setting that helps one objective can be irrelevant or harmful to another.

Also establish whether memory pressure is actually involved. Compare the affected interval with a normal interval using the same workload. If the symptom occurs without meaningful memory pressure, a swap-policy change may distract from a CPU, storage, network, or application issue.

Record the existing arrangement

Start with read-only inspection:

sysctl vm.swappiness
swapon --show
free -h

Record the current value rather than assuming that a distribution uses a particular default. The machine may inherit a local policy, a system image setting, or configuration-management changes. Record the kernel version and the active swap devices as well.

Check whether the setup includes zram, zswap, conventional storage-backed swap, or several layers. Comparing settings across machines with different memory mechanisms does not isolate the effect of the number. Our compressed-memory comparison explains why the underlying arrangement matters.

Keep a copy of the baseline output with your test notes. This is not busywork: it provides the exact information needed to reverse the experiment and makes the result meaningful when someone revisits it after a system upgrade.

Choose useful measurements

Track an outcome the workload owner cares about, such as completion time or a repeatable interaction delay. Add supporting observations about memory pressure and storage activity. The supporting metrics help explain the result, but they should not replace the actual objective.

On a Linux system with the relevant tools, vmstat 1 10 provides a short observation window. Pay attention to the sampling context and interpret later interval reports rather than mistaking the initial summary for current behavior. Capture measurements during the workload, not only after it ends.

Avoid adding the sizes of every process and assuming the total is an exact measure of uniquely occupied physical memory. Shared mappings and different accounting categories can complicate that arithmetic. When precision matters, use tooling that matches the question instead of improvising a total from unrelated columns.

Design a controlled experiment

Use the same input, application version, concurrency, and background workload for each run. Decide whether you are comparing a cold start or an already warmed session. Those conditions can change the result even when swappiness remains unchanged.

Repeat the baseline enough to see ordinary variation. A one-off improvement that is smaller than the normal difference between runs is weak evidence. Record unsuccessful runs as well as successful ones. Discarding an inconvenient stall produces a cleaner-looking report and a worse operational decision.

Choose one candidate value for a documented reason. For example, a machine with conventional swap storage and an interactive objective presents a different hypothesis from a machine using compressed memory-backed swap. The hypothesis should explain what you expect to improve and what you will watch for as a possible regression.

Keep the first change temporary

An administrator can use sysctl to make a runtime change, but first preserve the current value and ensure the experiment is authorized. A command such as sudo sysctl vm.swappiness=40 illustrates the syntax; 40 is not a recommendation or a promise of better performance.

Run the planned comparison and then restore the recorded original value when the experiment ends unless the change has been explicitly accepted. Do not assume that returning to a remembered distribution default restores the machine's actual previous configuration.

Temporary testing is particularly useful because a bad hypothesis can be abandoned without leaving an unexplained startup setting. On a shared or production machine, schedule this work rather than changing memory policy during an incident without coordination.

Judge benefits and regressions together

A lower swap occupancy number is not sufficient evidence of improvement. Ask whether the important task became faster or more responsive, whether other tasks suffered, and whether failures became more frequent. A configuration should be evaluated across the complete expected session.

Consider a hypothetical workstation that edits a large project while a background build runs. One setting might improve window switching but lengthen the build. Another might help the build while making the interface unpleasant. The appropriate decision depends on which trade-off the workstation owner accepts, not on which graph appears tidier.

Write down that trade-off explicitly. “Preferred because interactive editing stayed usable during the build, with an acceptable increase in build duration” is a defensible conclusion. “Preferred because less swap is always better” is not.

Persist only an accepted result

Once a change is supported by a representative test, use the distribution's normal sysctl configuration mechanism. Check for conflicting entries and identify which configuration-management system owns the setting. A locally created file can otherwise be overridden later or conflict with an organization-wide policy.

Include a comment explaining the workload and the test that motivated the value. Record a review trigger, such as a RAM upgrade, storage change, distribution upgrade, or major application change. Tuning is easier to maintain when the reason survives alongside the number.

After a planned reboot, inspect the effective setting rather than assuming persistence worked. Also repeat a small workload check. Configuration success and workload success are separate acceptance criteria, just as they were during the temporary experiment.

Know when tuning is not the answer

Swappiness cannot make an unbounded workload fit indefinitely. If a process grows continuously, investigate retained objects, expanding queues, caches, and concurrency. More detailed application diagnosis may offer a larger benefit than another policy experiment.

Likewise, a machine whose active workload consistently exceeds practical capacity may need fewer simultaneous tasks or more physical memory. Use the RAM memory swap planning page to distinguish a capacity decision from a reclaim-policy decision.

Do not combine changes to swappiness, compressed memory, cache policy, and application worker count into one experiment. Even a favorable result becomes difficult to explain or reproduce when too many variables move together.

Conclusion: test a hypothesis, not a folklore value

Swappiness expresses a memory-reclaim trade-off; it is not a percentage threshold and not a universal speed control. Its usefulness depends on the storage arrangement, memory mechanisms, workload, and outcome being measured.

Record the baseline, change one thing temporarily, repeat realistic work, and preserve only a demonstrated improvement. A clear experiment with an easy rollback is more valuable than a dramatic-looking number that nobody can explain.