2.6 Swapping behavior

http://lwn.net/Articles/83588/
2.6 Swapping behavior[Posted 5, 2004 by Corbet]

There have, recently, been a new round of complaints about how the 2.6kernel swaps out memory. Some users has been very vocal in their beliefthat, if they has sufficient physical memory, their applications should NE Ver be swappedout. These people get annoyed when they sit on their display in themorning and find that their office suite or web browser Is Unresponsive,and stays, that's, for some time. They get even more annoyed when they lookand see how much memory the kernel are using for caching file Contentsrather than Process memory. The obvious question to ask Is:couldn ' t Thekernel cut back a bit on the file caches and keep applications in memory?

The answer is and the kernel can made to behave that's by tweaking aruntime parameter, but it's not necessarily A good idea. Before Gettinginto that, however, it's worth noting that recent 2.6 kernels has a memorymanagement problem which can Caus E serious problems after an applicationwhich reads through entire filesystems (updatedb, say, or a backup) Hasrun. The problem is the slab cache ' s tendency to request allocations ofmultiple, contiguous pages; These allocations, when done on the Behestof filesystem code, can bring the system to a halt. A Patch has been merged which fixes thisparticular problem for 2.6.6.

The bigger issue remains, however:should the kernel swap out userapplications on order to cache more file contents? There is plenty ofarguments in favor of this behavior. Quite a few large applications set upbig areas of memory which they rarely, if ever use. IF application Memoryis occasionally forced to disk, the unused parts would remain there, andthat much physical memory would Be freed for more useful contents. withoutswapping application memory to disk and seeing-what's faulted back in,it was almost impossible to figure out whic H pages is not really needed. A large file cache is also a performance enhancer. The speedups that Comefrom has frequently-accessed data in memory is harder to see than theslowdowns caused by having To fault in a large application, but they canlead to better system throughput overall.

Still, there is the users who insist that, for example, a system backup Shouldnever force OpenOffice off to disk. They don ' t care how quickly a systemmaintenance application runs at the morning, but they care a lotabout how the System responds when they is at the keyboard. This wish wasexpressed repeatedly until Andrew Morton exclaimed:

I ' m gonna stick my fingers in my ears and sing "La La la" untilpeople tell Me "I set swappiness to zero and it didn ' t do w Hat iwanted it to do.

This helped quiet the debate as the parties involved looked more closely atthis particular parameter. Or, perhaps, it was just fear of Andrew ' ssinging. Either, it has become clear that most people is unaware ofwhat the "swappiness" parameter does; The fact that it had never been documented mayhave something to does with that.

So ... swappiness, which is exported to/proc/sys/vm/swappiness, is a parameter which sets the kernel ' sbalance between RECLA IMing pages from the page cache and swapping outprocess memory. The Reclaim code works (in a very simplified) bycalculating a few numbers:

The "distress" value is a measure of how much trouble the kernel are having freeing memory. The first time the kernel decides it needs to start reclaiming pages, distress would be zero; If more attempts is required, that value goes up, approaching a high value of 100.

Mapped_ratio is an approximate percentage of what much of the system ' s total memory are mapped (i.e. is part of a process ' s Address space) within a given memory zone.

Vm_swappiness is the swappiness parameter, and which is set to $ by default.

With those numbers in hand, the kernel calculates its "swap tendency":

	swap_tendency = MAPPED_RATIO/2 + distress + vm_swappiness;

If swap_tendency is below, the kernel would only reclaim Pagecache pages. Once It goes above that value, however, pages which is partof some process ' s address space would also be considered for re Claim. So,if life are easy, swappiness are set to $, and distress is zero,the system would not swap process memory until it reaches 80% of the total. Users who would like tonever see application memory swapped out can set swappiness to zero; Thatsetting would cause the kernel to ignore process memory until thedistress value gets quite high.

The swappiness parameter should do-a lot of users want, but it doesnot solve the whole problem. Swappiness is a global parameter; It affectsevery process on the system in the same. What's a number of people wouldlike to see, however, is a-to-a-individual applications forspecial treatment. Possible approaches include using the process's "nice" value to control memory behavior; A low-priority process would not being ableto push out significant amounts of a high-priority process ' s memory. Alternatively, the VM subsystem and the scheduler could become more tightlyintegrated. The scheduler already makes an effort to detect "interactive" processes; Those processes could is given the benefit of a larger workingset in memory. That's sort of thing is 2.7 work, however; The mean time,people who is unhappy with the kernel's swap behavior may want to tryplaying with the knobs which has B Een provided.