mmap内存占用问题

Sorehead

原帖由 思一克 于 2008-4-3 10:16 发表
系统会保留最小的物理内存用做基本的工作.

实在不够了就交换出.

再不够了就杀死某些倒霉的进程.

不知道版主是否了解这个杀死细节，能讲解一下其机制或算法嘛。
谢谢！

sjh_311

mark

flw

原帖由 flw2 于 2008-4-3 11:11 发表
是我理解有问题

int main(int argc, char* argv[])
{
        int fd = open("./futex",O_RDWR|O_CREAT, 0777);
        int fd2 = open("./futex2",O_RDWR|O_CREAT, 0777);

        lseek(fd,G,SEE ...

你的物理内存总大小是多少？
我觉得这个 700M 似乎和内存条大小有关。
我这里只有 210M。
我是 256M 的内存。
而且，我发现起十个八个本程序一点儿关系都没有，
占用的内存总大小维持不变。

因此，我觉得这个只是 OS 的一种优化，mmap 是可以不占内存的，但是如果有空闲内存，就会给它。
malloc 似乎做不到这一点吧？malloc 只能往 swap 分区换页，因此总大小会受到 swap 的限制，
但是 mmap 不会。我的 swap 也只有 256M。

flw

top - 11:47:44 up 2 days, 17:31,  4 users,  load average: 9.53, 6.80, 3.21
Tasks:  72 total,   4 running,  68 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3%us, 16.4%sy,  0.0%ni,  0.0%id, 79.5%wa,  3.7%hi,  0.0%si,  0.0%st
Mem:    256572k total,   252184k used,     4388k free,      272k buffers
Swap:   329292k total,    62964k used,   266328k free,   232712k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
9668 flw       20   0 2049m 136m 136m R  4.6 54.7   0:08.18 tmmap
9581 flw       20   0 2049m  44m  44m R  4.3 17.8   0:33.24 tmmap
9584 flw       20   0 2049m  43m  43m R  3.3 17.4   0:16.42 tmmap

flw

晕～
起第四个的时候，EBUS 了。

1. flw@debian:~/cis$ ../study/tmmap
   
2. 总线错误 (core dumped)
   
3. flw@debian:~/cis$

复制代码

哦，我知道了，总线错误是因为我的硬盘满了，文件操作失败了，并不是内存不够了。
我换个大硬盘的机器试试。
我感觉应该是十个八个一两百个问题都不大。

[ 本帖最后由 flw 于 2008-4-3 11:58 编辑 ]

flw

草草的做个总结吧，然后去吃饭：

1，malloc 和 mmap 极其相似，它们俩都不消耗物理内存，但是如果物理内存有富余的话，就会给它们用。
2，当物理内存紧张时（比如别的程序又需要申请一大笔内存），就会换页，将暂时用不到的页面交换到磁盘上去。
malloc 是交换到 swap（包括 swap 分区和 swap file），但是 mmap 则是交换到文件里去。

推论：
1，swap 分区总是有限的，因此所有进程总共可以 malloc 的内存总是有限的，
   但是 mmap 则只要磁盘空间足够，总是能成功，且不影响其它应用程序的正常运行（【重要】也就是不会随机 drop 倒霉进程）。
2，考虑只读的情况，mmap 不会比 malloc 更慢，因为它们俩的策略是相同的，都是优先使用物理内存，缺页时从磁盘上 load 页面。

[ 本帖最后由 flw 于 2008-4-3 12:22 编辑 ]

flw2

out_of_memory的策略不知道
__alloc_pages 里面在一定条件下会调用 out_of_memory函数，它会根据一些策略选择要杀死的进程
to flw: 我的是1G的 swap我不知道，我没有使用swap，也没看过相关资料
我觉得先不用考虑swap. 一旦用户态进程缺页， 那么可能有很多原因，比如至少有如下的几个：

1. 访问的地址不属于用户空间（内核能得到出错的线性地址，然后得知），那么将得到一个SIGSVEG信号
2. 访问的地址属于用户空间，但是这个地址所在的页还没有分配页框（比如分配一个大数组，然后写就会遇到这个情况），那是要分配物理地址，然后让该进程的对应页表项更新，继续执行缺页代码，就不会再缺页了
3. 地址空间内，但是检查到被交换出去了？ 然后调入，这同样需要分配物理内存
4. 其它

内核在分配内存的时候最底层的来自__alloc_pages， 这个函数肯定不一定能成功，在不成功的时候就可能会杀死进程, ULK上说了具体的步骤，分析了这个函数，这个函数也有人分析过，虽然步骤很多，但是分析后还是比代码强

flw真执着啊，赞一个

印随

munmap是 释放映射空间

为什么我循环调用mmap，munmap   剩余内存还是一直在减小？

flw2

原帖由 印随 于 2008-4-3 13:13 发表
munmap是 释放映射空间

为什么我循环调用mmap，munmap   剩余内存还是一直在减小？

一直？什么时候恢复了吗

flw

原帖由 印随 于 2008-4-3 13:13 发表
munmap是 释放映射空间

为什么我循环调用mmap，munmap   剩余内存还是一直在减小？

啥叫“剩余内存”？