一、關於2G虛擬內存限制的說明
1. 早期的linux對虛擬內存的限制
linux2.2以前的內核，支持最大128M的Linux swap分區或文件。Linux swap的分區或文件總數不超過16個。
所以在linux2.2以前，可用的最大虛擬內存為128M*8=1G。
2. Linux2.2.x對虛擬內存的限制
Linux2.2.x支持最大2G的Linux swap分區或文件。Linux swap的分區或文件總數不超過8個。
所以在Linux2.2.x，可用的最大虛擬內存為 2G*8=16G
3. Linux2.4.x對虛擬內存的限制
Linux2.4.10之前支持最大2G的Linux swap分區或文件。Linux swap的分區或文件總數不超過8個。
所以在 Linux2.4.10之前，可用的最大虛擬內存為 2G*8=16G
Linux2.4.10(含)之後支持最大2G的Linux swap分區或文件。Linux swap的分區或文件總數不超過32個。
所以在 Linux2.4.10之後，可用的最大虛擬內存為 2G*32=64G
Linux2.4.x在內存管理策略上，就如Windows98向Windows2000轉變一樣，在內存和交換區中保存了更多的髒頁，而不是及時回收內存，以此提高系統的效率。(見Widnows核心編程第18章的論述)。
此外，如果你有超過1塊磁盤，並且分別在不同的磁盤上建立了swap，那麼linux會按照raid 0的方式來使用這些交換分區。
二、多少虛擬內存較好？
1. Linux 2.2.x（含）及以前
傳統的2倍虛擬內存的觀點是有效的。建議按照此方法進行分配。
2. Linux 2.4.x（含）及以後
在考慮合適的硬盤費用的情況下，對虛擬內存的需求是多多益善。
Linus明確的指出，即使是512M內存，也可以分配高達40G的交換區，以提高系統的性能。Zlatko 在向Linus提出性能的質疑後，自己進行了驗證。Zlatko通過實驗表明：大交換區策略沒有增加磁盤I/O的費用。
三、實例
一台IBM x365服務器，配置4G內存。
1. 交換區最小不低於4G
建立兩個各為2G的交換區，做為基礎的4G交換分區
2. 建立8個2G的交換文件，做為擴展的交換分區
這樣總的交換分區大概在20G左右，如果硬盤更大，可以增加最多。
題外話：關於Windows中的虛擬內存使用
自Windows2000開始，微軟也改變了內存使用策略。他們會盡可能較遲的回收內存。因此，我個人相信大的交換區，對於Windows2000以上的系統也是更有效率的。
附：Linus的談話錄
2. Greater 2.4 Swap Requirements
7 Jan 2001 - 18 Jan 2001 (100 posts) Archive Link: "Subtle MM bug"
Topics: Virtual Memory
People: Rik van Riel, Linus Torvalds, Eric W. Biederman, Zlatko Calusic
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 should 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 512MB of RAM, you can probably afford another 40GB or so of harddisk. They are disgustingly cheap these days.
Zlatko Calusic worried that more data in swap would degrade performance because the disk head would need more seek time to find data. He asked if Linus was sure this would be okay, and Linus replied, "I'm not _sure_, obviously. 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 suclearcase/" target="_blank" >ccinctly, "The tradeoff when implemented correctly is that writes will tend to be more spread out and reads should be better clustered together."
Zlatko ran some tests, and could 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 magnitude 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 foolhardy 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 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 would have. Another way of putting this: in 2.2.x you could 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.
下面是我對其中一些論點的翻譯，由於本人英文水平的原因，一定會有不妥的地方。歡迎斧正。
在下面的討論中，清楚的說明了Linux2.4版本比它以前的版本需要更多的交換區。Rik val Riel提醒說：“2.4(內核) 在交換區緩存中，保持了更多的髒頁，所以對於相同的程序，你需要更多的內存來運行它...”。他問Linus Torvalds，“這是一些東西，我們需要保持，或者我們將告訴用戶，將要運行在某一種模式，當交換區被釋放，當我們在一些非共享區進行交換時？”Linus回答：“我樂於看見用文檔說明這點，並且將它保持下去。我痛恨兩種不公平的行為方式。它總是建議“兩倍於內存（的交換區大小）”，盡管在歷史上被告知，“Linux 實際上不需要那樣多”，我們在linux2.4.x中，把這種觀點真正的拋棄了。
如果你有512M內存，你可以要求40G的交換區，他們在今天已經變得非常便宜。
Zlatko Calusic 擔心，更大的交換區會降低性能，因為磁盤需要更多的時間進行搜索，以找到數據。他問Linus，是否確認這種現象不會發生，Linus回答：“我不 _確認_，眾所周知，無論如何，我只確認一件事情，即頁面緩沖的粘著性，能夠使許多事情變得簡化，並且使此前不可能的一些事情變得可能。”但是在最近，他補充道：“粘著建起可能會使我們的IO更為分散”。
Zlatko進行了一些測試，並沒有發現2.4.0版本的內存管理策略有什麼問題。他說道：“我發現新內核在某些環境下，會申請４倍的交換空間。這或許是，也或許不是問題，它仍然保持可見性。