Why do discussions of "swappiness" act as information, can they only be in one place at a time?

Question

I read about "swappiness" under Linux, which controls how aggressive the kernel is about replacing application memory with disk when not in use. If you use Google, you will get many pages such as this , discussing the pros and cons. In a nutshell, the argument is as follows:

If your swappiness is too low, inactive applications will process all system memory that other programs can use.

If your swappiness is too high when you wake these inactive applications, there will be a big delay, since their status will be read from the disk.

This argument does not make sense to me. If I have an inactive application that uses a ton of memory, why doesn't it load its memory to disk? Leave another copy of this data in memory? This seems to give the best of both worlds: if another application needs this memory, it can immediately require physical RAM and start writing to it, since another copy of it is on disk and can be replaced back when the inactive application is woken up. And when the original application wakes up, any of its pages, which are still in RAM, can be used as is, without having to pull them from disk.

Or am I missing something?

Answer 1

According to this 1, this is exactly what Linux does.

I'm still trying to understand a lot of this, so any authoritative links will be appreciated.

Answer 2

If I have an inactive application that uses a ton of memory, why doesn't it load its memory to disk? Leave another copy of this data in memory?

Let's say we did it. We wrote the page to disk, but left it in our memory. Some time later, another process needs memory, so we want to get the page out of the first process.

We need to know with absolute certainty whether the first process has changed the page since it was written to disk. If so, we should record it again. The way we keep track of this is to remove the write permission to the page back when we first burned it to disk. If the process tries to write to the page again, a page error will occur. The kernel may notice that this process has fouled the page (and therefore will need to be written out again) before restoring write permission and allowing the application to continue working.

This is the problem. Removing the write permission from this page is actually quite expensive, especially on multiprocessor machines. It is important that all processors clear their page translation cache to make sure they remove the write permission.

If the process writes to the page, the problem with the page is even more expensive. I assume that the non-trivial number of these pages will ultimately lead to this error, which absorbs the profit we were looking for, leaving it in our memory.

So is it worth it? Honestly, I do not know. I'm just trying to explain why leaving a page in my memory is not so obvious a victory as it sounds.

(*) All this is very similar to the Copy-On-Write mechanism used in the fork () s process. The child process is likely to follow only a few instructions and call exec (), so it would be foolish to copy all the pages of the parents. Instead, the write permission is removed and the child is simply allowed to run. Copy-On-Write is a win because a page error is almost never taken: a child almost always calls exec () immediately.

Answer 3

Even if you download application memory to disk and store it in memory, you still have to decide when the application should be considered “inactive” and what control is needed. Paging to disk is expensive in terms of I / O, and you don't want to do this too often. There is another variable in this equation, and it is the fact that Linux uses the remaining memory as disk buffers / cache.

Answer 4

The first thing that VM does is clean pages and move them to a clean list.
When clearing anonymous memory (things that do not have actual file backup storage, you can see segments in / proc // cards that are anonymous and do not have the vnode storage file system behind them), the first thing VM will do is take the dirty pages and "clear" and then write the contents of the page for sharing. Now that the virtual machine is running out of free memory and worried about its ability to provide new free pages that can be used, it can go through the list of "clean" pages and be based on how recently they were used and what memory they will be moving these pages are in a free list.

Once memory pages are put on a free list, they are no longer associated with the content they had before. If the program indicates the location of the memory on which the page used to be, the program will have a serious error, and the page will be grabbed from the free list (most likely, completely different), and the data will be read from the disk on the page. Once this is done, the page actually remains “clean” because it has not been modified. If the VM decides to use this page as a swap for another page in RAM, then the page will be "dirty" again, or if the application writes to this page, it will be "dirty". And then the process begins again.

In addition, swappinness is quite terrible for server applications in a business / transaction / online / latency environment. When I have 16 GB RAM boxes where I don’t run many browsers and graphical interfaces, I usually want all my applications to be almost locked in memory. The bulk of my memory is usually 8-10 GB java heaps, which I NEVER want to unload to disk, ever, and the available crates are processes like mingetty (but even there glibc pages are used in these applications it is actually used by other applications, so even the RSS size of these useless processes is mainly used by shared pages). Usually I don't see more than a few 10 MB of 16 GB actually cleared of sharing. I would recommend very, very low numbers of swappiness or zero swappiness for servers - unused pages should make up a small part of the total RAM and try to restore this relatively small amount of RAM for the risks of cache cache, swapping application pages and accepting latent calls to a running application.