[摘要]Pushing the Limits of Windows: Virtual Memory From Mark Russinovich's blog

This an abstract to Russinovich's blog:
Pushing the Limits of Windows: Virtual Memory(http://blogs.technet.com/markrussinovich/archive/2008/11/17/3155406.aspx)

我阅读之后,吸收了原文的精华,把我的糟粕留在了这里。

Process Address Spaces
1。32位的处理器使用32位的地址自然有个上限4G
2。Windows自然也分配了一段地址给内核,目的自然是可以在不同process context中访问数据,而不用切换context,这个值默认是2G,最小可配置为1G,也就是说把3G的空间留给user mode process.
   (参考/3GB选项http://msdn.microsoft.com/en-us/library/ms791558.aspx)
3。0~2G为user mode,那么80000000开始就是kernel mode了。
4。无论是new,malloc或者.NET garbage collector,本质上都是调用Windows的VirtualAlloc(http://msdn.microsoft.com/en-us/library/aa366887(VS.85).aspx)函数。
5。(问题?Windbg下如何看当前进程使用了多少Virtual Address Size? 注意Virtual Address Size不一定意味着分配了物理内存)
6。很有趣的一个思考,即使Windows配置了/3GB选项。process默认也不可能得到高于2G的地址,a process must have the ‘large address space aware’ flag set in its executable image。比如说有一个程序已经假设了它最多可以得到2G的地址,那么一个指针的最高bit,就永远为0,也就是说,程序可以用这个bit位做一些事情。/3GB是后来才加入到Windows家族的,这样的设定是为了兼容以前的老程序,我想在如今内存如白菜价的年代,很少有人考虑到节约到这个bit吧。
7。可以用VS中的Dumpbin工具看看MS server产品的程序,如Lsass.exe,Smss.exe,他们都设了large address space aware flag.
8。64位处理器理论值自然是2^64了,不过Windows并没有均匀的在process和system中分配使用,而是分成了多个region. IA64和x64的分配不一样,不过我没细看,现在还没有在64位上工作。

Committed Memory
1. Reserve virtual memory, but not actually commit it,so comes "commit limit"
2. "commit limit" is the sum of physical memory and the sizes of the paging files. 当然了不是所有的physical memory都可用于process commit,系统保留了一部分物理内存给自己使用。
3. 在WinXp的资源管理其中,Commit charge就是描述"commit"的。
   Total的意思是当前所有的process commit了多少内存
   Limit就是上限,也就是物理内存和paging file的大小之和。
   在Win7中,对应的地方在"Commit(MB)  1234/2042"

Process Committed Memory
上面讨论的是全局的Committed Memory限制,那么一个process分配何种的内存能够会计为current Commit charge呢?至少Reserved memory不会。如果用来是映射文件的地址区间也不会记入current Commit charge.
Private virtual memory是进程内私有的内存,无法在进程之间共享,这是一种current commit charge.
Pagefile-backed virtual memory是在process间共享,他会记入全局的commit charge.
(这一节看得语焉不详,需要进一步的分析)

How Big Should I Make the Paging File?
结论是:这个问题很难说,哈哈。

原文地址:https://www.cnblogs.com/aoaoblogs/p/1606454.html