返回信息流#include <stdio.h>
#define Malloc(sizeMB) malloc(sizeMB*(1<<20))
int main(){
- int k = 0;
| while (1)
| {
if( Malloc(1) == NULL )
||- break;
|| k++;
|| printf("k=%d\n",k);
| }
| return 0;
}
结果是3057
我内存是有512
这是一条镜像帖。来源：北邮人论坛 / soft-design / #9154同步于 2006/6/26
该镜像源已超过 30 天没有更新，可能在源站已被删除。
SoftDesign机器人发帖
（转贴）看这个程序的结果？
wizardcicici
2006/6/26镜像同步9 回复
订阅后，新回复会通过你的通知中心匿名送达。
9 条回复
1<<20
这句中1的数据类型默认是什么呢？
1MB=20bit，理论上一次Malloc(1)是申请1MB内存，这个程序是计算你的内存可用空间，
这个程序我觉得和物理内存大小ms没啥关系，应该是虚拟内存+物理内存-被占用的内存
比较奇怪了，物理内存加虚拟内存也才是512M+1000M
【 在 zwz (Zigeunerweisen) 的大作中提到: 】
: 1<<20
: 这句中1的数据类型默认是什么呢？
: 1MB=20bit，理论上一次Malloc(1)是申请1MB内存，这个程序是计算你的内存可用空间
: ，
: ...................
【 在 wizardcicici 的大作中提到: 】
: 比较奇怪了，物理内存加虚拟内存也才是512M+1000M
我用Dev-c++4.9.9.2下执行结果是700+，我的物理内存+虚拟内存大概1G,大致符合，你用的是TC么？我记得TC好像是16位的。
位操作的结果跟编译器有关。
具体我也不太清楚，等牛人吧
我是内存512M
交换分区是1G
gcc
linux
【 在 zwz (Zigeunerweisen) 的大作中提到: 】
: 我用Dev-c++4.9.9.2下执行结果是700+，我的物理内存+虚拟内存大概1G,大致符合，你
: 用的是TC么？我记得TC好像是16位的。
: 位操作的结果跟编译器有关。
: 具体我也不太清楚，等牛人吧
: ...................
我的比较正常，系统是win2k+vc6.0
256＋512虚拟页面
最后K接近700，
分析它的VAD和虚拟地址到物理地址映射，也比较正常，
有效PTE近500多个(这时K也是500多，还没到700，我加了判断，K每过100停一下)
最后K到600多的时候，我写的那些内核分析工具已经不能正常工作了，因为内存被
用完了，分配不到内存了已经。最近虚拟机就死机了，ft...
linux下的内存管理不清楚，不过从数据上看，能到3000多，可能你分配到一定数量
时，只写相关PTE，但不设置有效位，当你实际往内存里写的时候，才设置有效，所
以分配到的地址位于虚拟地址空间，有4G大小，能上3000M也不足奇怪。（上以纯属
猜测，我没研究过linux内核，不过PTE和PDE的二级映射是x86的共性，这点都一样）
【 在 wizardcicici (度边) 的大作中提到: 】
: #include <stdio.h>
: #define Malloc(sizeMB) malloc(sizeMB*(1<<20))
: int main(){
: ...................
man malloc:
BUGS
By default, Linux follows an optimistic memory allocation strategy.
This means that when malloc() returns non-NULL there is no guarantee
that the memory really is available. This is a really bad bug. In case
it turns out that the system is out of memory, one or more processes
will be killed by the infamous OOM killer. In case Linux is employed
under circumstances where it would be less desirable to suddenly lose
some randomly picked processes, and moreover the kernel version is suf-
ficiently recent, one can switch off this overcommitting behavior using
a command like
# echo 2 > /proc/sys/vm/overcommit_memory
See also the kernel Documentation directory, files vm/overcommit-
accounting and sysctl/vm.txt.
如果不用echo 2 > /proc/sys/vm/overcommit_memory,我的结果是3075,否则是1248,我的内存是700+1000M
/usr/src/linux-2.6.14/Documentation/vm/overcommit-accounting:
The Linux kernel supports the following overcommit handling modes
0 - Heuristic overcommit handling. Obvious overcommits of
address space are refused. Used for a typical system. It
ensures a seriously wild allocation fails while allowing
overcommit to reduce swap usage. root is allowed to
allocate slighly more memory in this mode. This is the
default.
1 - Always overcommit. Appropriate for some scientific
applications.
2 - Don't overcommit. The total address space commit
for the system is not permitted to exceed swap + a
configurable percentage (default is 50) of physical RAM.
Depending on the percentage you use, in most situations
this means a process will not be killed while accessing
pages but will receive errors on memory allocation as
appropriate.
The overcommit policy is set via the sysctl `vm.overcommit_memory'.
The overcommit percentage is set via `vm.overcommit_ratio'.
The current overcommit limit and amount committed are viewable in
/proc/meminfo as CommitLimit and Committed_AS respectively.
Gotchas
-------
The C language stack growth does an implicit mremap. If you want absolute
guarantees and run close to the edge you MUST mmap your stack for the
largest size you think you will need. For typical stack usage this does
not matter much but it's a corner case if you really really care
In mode 2 the MAP_NORESERVE flag is ignored.
How It Works
------------
The overcommit is based on the following rules
For a file backed map
SHARED or READ-only - 0 cost (the file is the map not swap)
PRIVATE WRITABLE - size of mapping per instance
For an anonymous or /dev/zero map
SHARED - size of mapping
PRIVATE READ-only - 0 cost (but of little use)
PRIVATE WRITABLE - size of mapping per instance
Additional accounting
Pages made writable copies by mmap
shmfs memory drawn from the same pool
Status
------
o We account mmap memory mappings
o We account mprotect changes in commit
o We account mremap changes in size
o We account brk
o We account munmap
o We report the commit status in /proc
o Account and check on fork
o Review stack handling/building on exec
o SHMfs accounting
o Implement actual limit enforcement
To Do
-----
o Account ptrace pages (this is hard)
【 在 wizardcicici (度边) 的大作中提到: 】
: #include <stdio.h>
: #define Malloc(sizeMB) malloc(sizeMB*(1<<20))
: int main(){
: ...................
malloc是posix.1标准，m$也支持这个标准，内部实现和*nix会不太一样。
【 在 zwz (Zigeunerweisen) 的大作中提到: 】
: 同样的函数在不同系统下也不一样啊。。。。。
: 恩，又学到新东西了，哈哈