mmap内存占用问题

flw2

原帖由 思一克 于 2008-4-2 17:53 发表
不一定是128M界限.

你可以编个小程序, 分配256M, 前后打印出BRK数值, 你会看到不变化了. 因为是直接用mmap了, 没有用brk.

我试了，是没有brk

flw2

是我理解有问题

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,SEEK_SET);
        write(fd, "0", 1);

        lseek(fd2,G,SEEK_SET);
        write(fd2, "0", 1);
        char *base = mmap(NULL,G,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0);
        char *base2 = mmap(NULL,G,PROT_READ|PROT_WRITE,MAP_SHARED,fd2,0);
        char *p;

        for (p = base; p < base + G; p += 4096)
                *p = 'a';

        for (p = base2; p < base + G; p += 4096)
                *p = 'a';

        return 0;
}
现象是总是占用内存在700M左右，应该是系统会从它占用的内存中回收

flw2

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

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

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

flw真执着啊，赞一个

flw2

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

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

一直？什么时候恢复了吗

flw2

原帖由 flw 于 2008-4-3 15:07 发表

分段映射呢？
比如每次只映射一小部分。

我的理解是没关系， 那段英文也提到了，说可以分段释放

很多不好daemon通常会有个buf，然后越来越大
char data[10M]；
然后保持最大在10M，如果超过就删除某些旧的数据， 但是这个后果就是某段时间过后，内存占用大于10M，即使daemon只是偶尔需要10M
所以可以mmap一个，然后释放，这样就可把物理内存真正的归还给系统，在需要时增加一些，对于一些偶尔要求大内存块，但是通常却不需要的daemon很好

flw2

如果munmap还不归还，那就没法归还了，就算内核暂时不回收，那么它也是属于内核管理的