Per the kernel documentation:

This control is used to define how aggressive the kernel will swap
memory pages.  Higher values will increase aggressiveness, lower values
decrease the amount of swap.

However this is kind of vague. I'm trying to figure out exactly what the parameter ultimately controls. I know it adjusts how aggressively the kernel tries to swap out pages, but what decision making process in the kernel code does it affect?

Does it adjust how long ago a page must have been accessed before the kernel swaps it out? If so what does the default value of 60 represent? And how much is changed by a increment/decrement of 1 (a formula would be nice)?
Or does it swap out pages based on their access frequency?
Or something else?

  • 3
    Yes, swapiness is vague ;-)
    – raphink
    Commented Feb 22, 2012 at 10:21
  • See also an amazing article In Defence Of Swap. It is referred to by systemd-oomd documentation in "Notes".
    – Hi-Angel
    Commented Mar 8, 2021 at 17:17

3 Answers 3


Since kernel version 2.6.28, Linux uses a Split Least Recently Used (LRU) page replacement strategy. Pages with a filesystem source, such as program text or shared libraries belong to the file cache. Pages without filesystem backing are called anonymous pages, and consist of runtime data such as the stack space reserved for applications etc. Typically pages belonging to the file cache are cheaper to evict from memory (as these can simple be read back from disk when needed). Since anonymous pages have no filesystem backing, they must remain in memory as long as they are needed by a program unless there is swap space to store them to.

The vm.swappiness option comes into play in get_scan_count() defined in mm/vmscan.c. get_scan_count() determines how aggressively the anonymous and file LRU lists should be scanned when looking for pages to evict. The value of each case is is determined by the floating average of recently rotated and recently scanned ratios where more recent references have more weight than older ones in order take into account the changing workload of the system.

The vm.swappiness is a modifier that changes the balance between swapping out file cache pages in favour of anonymous pages. anon_prio=vm.swappiness is the priority value given to anonymous pages, by default set to 60. The file cache is given a priority value of 200 from which the vm.swappiness modifier is deducted, file_prio=200-anon_prio. This means that, by default (anon_prio=60, file_prio=140), the system considers the cost of reclaiming anonymous pages more than twice the cost of reclaiming file pages. Therefore, the lower vm.swappiness, the more file cache pages are swapped out in favour of anonymous pages. However, when the system is close to an out-of-memory condition, both anonymous and file LRU lists are scanned equally, unless vm.swappiness is set to zero.

When vm.swappiness is set to 100, the priorities would be equal (anon_prio=100, file_prio=200-100=100). Setting vm.swappiness to zero will prevent the kernel from evicting anonymous pages in favour of pages from the file cache.

  • Is there a way to change the swappiness of file_prio? Or limit it to a particular directory? Commented Jul 25, 2014 at 6:40

There is a formula which is used to compute what page will be swapped. In vmscan.c you can see this algorithm:

swap tendency = mapped_ratio / 2 + distress + vm_swappiness

Here you can see that swappiness is a scale, which is added in some algorithm and you can control by this parameter how the kernel will behave when it must swap. You can figure it as an percentage of probability, that some inactive memory page will be swapped. If you set swappiness to 100, there is no probability, but a guarantee that it will swap and if you set it to 0, the kernel will try not to swap at all as long as it has some empty memory.


It has been said (I think Norman 1986) that often the "CLOSE DOOR" button in an elevator is either broken or never was connected to anything in the first place. This makes the ersatz control not a way of manipulating the elevator but of pacifying the over-hurried rider.

In a similar fashion, swappiness has an effect unrelated to its well-defined, deterministic control of a kernel predicate. As was noted by @neon_overlord on askubuntu.com

Because most believe that swapping = bad and that if you don't reduce swappiness, the system will swap when it really doesn't need to. Neither of those are really true. People associate swapping with times where their system is getting bogged down - however, it's mostly swapping because the system is getting bogged down, not the other way around. It's true that there are certain times when swapping can have a noticeable penalty, but reducing swappiness for that case can reduce overall system performance or stability in other ways which may later become noticeable…

So what does it really control? One valid answer — in addition to the fine answers already provided — is that it modifies your expectation that you have more control over your system and that twiddling a knob will allow you to exert that control in a meaningful fashion.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .