一个进程可以分配多大的内存?

Alligator27

原帖由 congli 于 2006-3-28 09:52 发表

哦,明白了,
管理员跟普通用户不同;
root:Allocated 1022 MB total.
普通用户:Allocated 511 MB total.

是因为 ulimit 设置不一样?

Alligator27

补充一句:

PT2 malloc (大多数Linux): 如果size>256KB, 内存是mmap()得来的. 否则是用sbrk(). 这个值可编程修改.
Debian/Novell 的Hoard是64KB.

Alligator27

malloc 是在用户空间, 不会管理页面. 那是kernel的事.

我试了一下, Linux/AIX的mmap是由下向上的, Solaris/HP-UX与BSDs相似, 由上向下. (BSDs我没有机器试, 以上面贴的Document说.)

我的测试程序及结果如下.

1. 
   
2. 
   
3. #include <stdio.h>
   
4. #include <stdlib.h>
   
5. #include <unistd.h>
   
6. #include <errno.h>
   
7. #include <sys/mman.h>
   
8. 
   
9. int main(void)
   
10. {
    
11.     char *p;
    
12. 
    
13.     size_t pgsize = ::sysconf(_SC_PAGE_SIZE);
    
14.     size_t size = 2*pgsize;
    
15. 
    
16.     for(int i=0; i<10; i++)
    
17.     {
    
18.                 p = (char*) ::mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
    
19.                 if (!p)
    
20.                 {
    
21.                         fprintf(stderr, "Failed: mmap size=%ld", size);
    
22.                         exit(errno);
    
23.                 }
    
24.                 printf("p(%d) = 0x%lx\n", i, p);
    
25.         }
    
26. 
    
27.     return 0;
    
28. }
    
29. 
    

复制代码

1. 
   
2. ======== RedHat AS 3 / x86_64 ==========
   
3. p(0) = 0x2a9566d000
   
4. p(1) = 0x2a95670000
   
5. p(2) = 0x2a95672000
   
6. p(3) = 0x2a95674000
   
7. p(4) = 0x2a95676000
   
8. p(5) = 0x2a95678000
   
9. p(6) = 0x2a9567a000
   
10. p(7) = 0x2a9567c000
    
11. p(8) = 0x2a95d2c000
    
12. p(9) = 0x2a95d2e000
    
13. ======== Solaris / sparc ==========
    
14. p(0) = 0xff160000
    
15. p(1) = 0xff030000
    
16. p(2) = 0xff020000
    
17. p(3) = 0xff010000
    
18. p(4) = 0xff000000
    
19. p(5) = 0xfeff0000
    
20. p(6) = 0xfefe0000
    
21. p(7) = 0xfefd0000
    
22. p(8) = 0xfefc0000
    
23. p(9) = 0xfefb0000
    
24. ======== HP-UX / IA64 ==========
    
25. p(0) = 0x7efb4000
    
26. p(1) = 0x7efb2000
    
27. p(2) = 0x7efb0000
    
28. p(3) = 0x7efae000
    
29. p(4) = 0x7efac000
    
30. p(5) = 0x7efaa000
    
31. p(6) = 0x7efa8000
    
32. p(7) = 0x7efa6000
    
33. p(8) = 0x7efa4000
    
34. p(9) = 0x7efa2000
    
35. ======== AIX / PPC ==========
    
36. p(0) = 0x30000000
    
37. p(1) = 0x30002000
    
38. p(2) = 0x30004000
    
39. p(3) = 0x30006000
    
40. p(4) = 0x30008000
    
41. p(5) = 0x3000a000
    
42. p(6) = 0x3000c000
    
43. p(7) = 0x3000e000
    
44. p(8) = 0x30010000
    
45. p(9) = 0x30012000
    

复制代码

Alligator27

我明白你的意思了.  我试的RedHat AS 3 是linux 2.4.21 kernel

不过malloc用作管理的内存是不应该叫页面的. 而且我所知的malloc都不用mmap来获得这部分内存, 起码这样大大减少了用户的default heap空间, 如果mmap不是从顶往下.

Linux RedHat 不是这样的.

前面数据是非常规则的线性关系. 但我觉得不是因为malloc不能mmap到它想要的内存.

Alligator27

不错, 不是malloc大大减少用户的default heap空间, 而是vmm对mmap的布局造成的.

我能想到的唯一原因, VMM把mmap从下向上排, 可能是backword compatibility. 有些老程序, 也许依赖于stack是很深的.

Alligator27

原帖由 雨丝风片 于 2006-3-29 10:08 发表



呵呵，反正就是个名字，叫什么还不都一样，。在没有特别注明的情况下，我所指的都是FreeBSD/NetBSD目前使用的malloc，作者为Poul-Henning Kamp。在这个malloc里，它的“page”定义为4K大小，它就是 ...

刚看了PHK malloc 和他写的 "Malloc Revisited". 你说的没错, PHK malloc 确实是mmap一块内存作page-directory. 他根据brk的值确定需要的page-directory的大小. 所以32bit进程大约要3GB/4KB*4Bytes=3MB. 考虑到不是一次分配, 6MB 的空间就够了. 一些shared libs在占一些mmap空间. 还是有一点对不上数.

PHK malloc 做得不错, 但有几点不好, 让我有点意外.
1 page-directory的大小是根据brk的值确定, 象LZ的测试程序是1MB的内存块, 与同样总内存但是1KB的内存块要分配同样大小的page-directory, 有点浪费.
2 brk() 失败后, 没有用mmap. 这样有不少空间没法给用户.
3 page-directory应当一次性分配, 而不要expand.

蛮有意思.

对了, Linux的malloc就是Kamp说的gnumalloc. 更常叫的是PTmalloc2(Wolfram Gloger), 或Doug Lea malloc.

[ 本帖最后由 Alligator27 于 2006-3-31 10:25 编辑 ]

Alligator27

原帖由 雨丝风片 于 2006-3-30 15:24 发表

page directory的大小确实是根据brk的内存大小来确定的，不知道你所说的浪费是指什么？page directry是用来管理malloc内部4K大小的page的，因此每个page都会对应一个条目。但page仅仅是malloc和内核的交易单位， ...

Excellent work!  

让我解释一下我的意思.

1 如果把page directory看成一个array, 它的index是page number, 它的element是该page的管理信息(meta data). 如果用户程序的内存申请size远大于pagesize, 象LZ的测试程序是1MB的内存块, 那么page directory是sparse array. 所以我说有点浪费.

2 malloc不考虑mmap是不行的. 特别象FreeBSD, default heap的顶被mmap area固定了. 当brk到这个顶的时候, 用户不能再得到内存, 但mmap area还有很多空间. 这不是米饭/馒头的选择, 会饿死的. 换句话说, 不管kernel把mmap起始地址放哪儿, malloc都应当分配出~3GB给用户程序.

3 page-directory一次性分配只需要3MB (32bit), 而且只是virtual address. 完全值得. 第一, 只有一个sysem call. 第二, 不会有将来分配不到的可能. 第三, 因为不搬家,实际占用空间可能少一些.

Alligator27

原帖由 雨丝风片 于 2006-3-31 08:54 发表

1、page目录中的条目和malloc管理的page之间有一一对应的关系，这和用户申请内存的大小是无关的。每个页面都要在这儿登个记，因此应该没有“稀疏”的问题。你的意思是不是说如果用户申请的内存是1M，相当于256个 ...

我们是从不同的角度看这个问题.

1 同意. PHK的用意是page mapping. 我想说的是, 它是作的最坏打算, 既用户的粒度是page. 如果用户使用大内存块, 它就有浪费, 虽然不多, 因为一个用户块实际上只需要一条目录. 不过使用mapping的malloc都是这样, 无可厚非. 只是在你的测试中显示出这个问题.

2 用户是不用关心内存是从main heap, 还是从mmap里来的, 这点我完全同意. 但用户一定想用尽量多的内存, 不管从哪儿来, 怎么来, 我只要不断malloc, 它就应当给我3GB. 这是PHK最大的缺点. 我想这也是该帖的主题.

3. 库函数可不可以抢地盘. 看你问谁了. 有些用户可能会panic. 因为"hello world"的memory footprint 就有3MB. 但不会有什么实际影响的.