Summary on swap of linux swap Partition

Summary of some understanding of linux swap partition swap-general Linux technology-Linux programming and kernel information. The following is a detailed description. Swap is something that all linuxer contacts, but most people don't pay attention. In fact, we have a lot of knowledge about small things. This is not a hot question about swap. It is very helpful for you to summarize it here. For more information, see here. The details are as follows:

In the debian and fedora documents, we can see that the swap partition should not exceed 2 GB. In fact, linux 2.6 and later kernels can directly support a memory of no more than 64 GB. Ext3 and other log file systems can also directly support a single file larger than 2 GB. Therefore, for swap within 64 GB, creating a single partition or file does not affect the memory Mace of the system.

Linus once pointed out in a mail discussion:

In the course of discussion, it became clear that Linux 2.4.x required more swap than previous versions. rik van Riel mentioned, "2.4 keeps dirty pages in the swap cache, so you will need more swap to run the same programs ..." He asked Linus Torvalds, "is this something we want to keep or shoshould we give the user the option to run in a mode where swap space is freed when we swap in something non-shared?" Linus replied:

I 'd prefer just documenting it and keeping it. I 'd hate to have two fairly different modes of behaviour. it's always been the suggested "twice the amount of RAM", although there's historically been the "Linux doesn't really need that much" that we just killed with 2.4.x.

If you have 512 MB of RAM, you can probably afford another 40 GB or so of harddisk. They are disgustingly cheap these days.

Zlatko Calusic worried that more data in swap wowould degrade performance because the disk head wowould need more seek time to find data. he asked if Linus was sure this wocould be okay, and Linus replied, "I'm not _ sure _, obviusly. however, one thing I _ am _ sure of is that the sticky page-cache simplifies some things enormously, and make some things possible that simply weren't possible before. ". but in a nearby post he admitted, "the sticky allocation _ might _ make the IO we do be more spread out. he felt it was important to consider these kinds of potential downsides, though he felt that in this case the benefits outweighed the drawbacks; and at one point Eric W. biederman explained succinctly, "The tradeoff when implemented correctly is that writes will tend to be more spread out and reads shocould be better clustered together."

Zlatko ran some tests, and cocould not find any problems with the 2.4.0 memory management logic, though he added, "I have found that new kernel allocates 4 times more swap space under some circumstances. that may or may not be alarming, it remains to be seen. "At one point, Linus gave his overall take on 2.2/2.4 performance issues. he said:

I personally think 2.4.x is going to be as fast or faster at just about anything. we do have some MM issues still to hash out, and tuning to do, but I'm absolutely convinced that 2.4.x is going to be a _ lot _ easier to tune than 2.2.x ever was. the "scan the page tables without doing any IO" thing just makes the 2.4.x memory management several orders of magn?more flexible than 2.2.x ever was.

(This is why I worked so hard at getting the PageDirty semantics right in the last two months or so-and why I released 2.4.0 when I did. getting PageDirty right was the big step to make all of the VM stuff possible in the first place. even if it probably looked a bit foolhard to change the semantics of "writepage ()" quite radically just before 2.4 was released ).

Elsewhere, he considered the case of swapless or low-swap machines:

If you don't have any swap, or if you run out of swap, the major difference between 2.2.x and 2.4.x is probably going to be the oom handling: I suspect that 2.4.x might be more likely to kill things off sooner (but it tries to be graceful about which processes to kill ).

Not having any swap is going to be a performance issue for both 2.2.x and 2.4.x-Linux likes to push inactive dirty pages out to swap where they can lie around und without bothering anybody, even if there is no _ major _ memory crunch going on.

If you do have swap, but it's smaller than your available physical RAM, I suspect that the Linux-2.4 swap pre-allocate may cause that kind of performance degradation earlier than 2.2.x wowould have. another way of putting this: in 2.2.x you cocould use a fairly small swap partition to pick up some of the slack, and in 2.4.x a really small swap-partition doesn't really buy you much anything.

During the discussion, Linus clearly stated that in Linux2.4.x, memory management (MM) policy changes. Just like the transformation from Windows 98 to Windows, Microsoft saves more dirty pages in both the memory and the swap zone, rather than timely memory collection, which greatly improves the system efficiency. (See Chapter 18th of Widnows core programming ).

Linus also pointed out that even MB of memory can be allocated up to 40 Gb swap zone to improve system performance. Zlatko verified the performance of Linus. The experiment shows that the large swap zone policy does not increase disk I/O traffic.

So, is swap necessary? Many people think that, in fact, in the general sense, the so-called swap is twice the memory, but it is only an experience value for beginners, the actual size of swap is adjusted based on the program's memory usage. Swap is unnecessary if the machine does not have much memory at runtime.

The problem becomes that I don't know the maximum memory requirements of all tasks. What should I do?

You can take one step and one step:
1. Use swapoff to turn off all swap and run the task normally. If the memory is insufficient, gradually increase the number of swap instances.
2 In general, the physical memory reaches 256 MB, so no swap partition is required during installation.
3. You can create swap partitions or swap files after installation.