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

gvim

原帖由 assiss 于 2007-4-21 17:52 发表
这是一次很经典的讨论。
我想可以复制其成功经验。

支持GVIM的意见，是不是你们一起出面组织一些讨论？

我现在的公司上网不是很方便,家里也还没有开网线, 所以组织论题的事情需要其他几位版主和相关高手筹划.
我觉得要推广BSD一个很关键的问题是驱动, 所以我从春节到现在的闲暇时间一直都在整{Free, Net}BSD的驱动(我的blog里有一些没来得急整理和完成的东西), 目前正在分析USB这一块,希望可以尽快完成框架.

如果大家有兴趣讨论{Free, Net}BSD驱动方面的问题,我想大家可以一起讨论. 呵呵.

[ 本帖最后由 gvim 于 2007-4-21 18:31 编辑 ]

雨丝风片

原帖由 assiss 于 2007-4-21 17:52 发表
这是一次很经典的讨论。
我想可以复制其成功经验。

支持GVIM的意见，是不是你们一起出面组织一些讨论？

好建议。只要有好的话题，不需要组织就可以讨论得很精彩。不必为了讨论而讨论，最好就像这次一样，以解决某个实际问题为目标，顺藤摸瓜，越摸越深。。。

雨丝风片

原帖由 gvim 于 2007-4-21 18:04 发表
我现在的公司上网不是很方便,家里也还没有开网线, 所以组织论题的事情需要其他几位版主和相关高手筹划.
我觉得要推广BSD一个很关键的问题是驱动, 所以我从春节到现在的闲暇时间一直都在整{Free, Net}BSD的驱 ...

51之后我们两个面谈一下。。。:em11:

congli

原帖由 雨丝风片 于 2007-4-21 22:33 发表


51之后我们两个面谈一下。。。:em11:

不是应该说会师一下吗

panabit

原帖由 雨丝风片 于 2006-3-28 17:14 发表



辛苦辛苦！

从试验结果来看，的确是随着数据段的逐渐增长，mmap的生存空间被不断压缩，使得基于mmap的各种库陆续出现分配不到空间的情况，最终导致系统启动失败。

另外，在2934M之前，实际ma ...

无所谓mmap空间被压缩这样的概念。
mmap是所有内存分配的根源，无论你是使用malloc，还是其它方法，最终都是通过mmap来实现的。
所谓的数据段，代码段和堆栈，那只是程序语言系统的概念，OS并不理会这些。
这些段的映射都是通过mmap来实现的。

还是那句话，mmap是OS所提供的，open给应用程序的唯一一个API接口。
在Unix里，mmap是一个非常重要的API，它关联了内存和文件这连个重要的资源。

crastyl

还有高手

雨丝风片

原帖由 panabit 于 2008-10-9 14:13 发表
无所谓mmap空间被压缩这样的概念。
mmap是所有内存分配的根源，无论你是使用malloc，还是其它方法，最终都是通过mmap来实现的。

当时讨论中使用的“mmap空间”只是对“文件内存映射和匿名内存区域”的一个形象描述，并非技术术语，
这个结合讨论上下文即可理解。

原帖由 panabit 于 2008-10-9 14:13 发表
所谓的数据段，代码段和堆栈，那只是程序语言系统的概念，OS并不理会这些。
这些段的映射都是通过mmap来实现的。

请参考：http://blog.chinaunix.net/u/9831/showart_110254.html

原帖由 panabit 于 2008-10-9 14:13 发表
无所谓mmap空间被压缩这样的概念。
mmap是所有内存分配的根源，无论你是使用malloc，还是其它方法，最终都是通过mmap来实现的。
所谓的数据段，代码段和堆栈，那只是程序语言系统的概念，OS并不理会这些。
这些段的映射都是通过mmap来实现的。

还是那句话，mmap是OS所提供的，open给应用程序的唯一一个API接口。
在Unix里，mmap是一个非常重要的API，它关联了内存和文件这连个重要的资源。

我无法从你的整段描述的上下文中判断出所出现的每一处“mmap”是指系统调用还是其它的什么东西。
如果你全部都指得是mmap系统调用，那么你的整段描述就是混乱的。而且，可以明确的说，在我们所
讨论的malloc库函数版本里，他所使用的动态内存是通过两个系统调用获取的，一个是brk，一个是mmap。
不过我想，在你整段描述中出现的“mmap”的含义似乎并没有这么明确。

综合你的：“mmap是OS所提供的，open给应用程序的唯一一个API接口。”
“这些段的映射都是通过mmap来实现的。”
是否可以推论出：“应用程序”是通过“mmap”这个唯一的“API”来映射自己的数据段、代码段和堆栈的？

panabit

原帖由 雨丝风片 于 2008-10-17 16:10 发表


当时讨论中使用的“mmap空间”只是对“文件内存映射和匿名内存区域”的一个形象描述，并非技术术语，
这个结合讨论上下文即可理解。



请参考：http://blog.chinaunix.net/u/9831/showart_110254.htm ...

有几个层面的东西需要分开：

1. OS层面

   在OS眼里，如果从内存管理角度看，它基本上不意识到某个程序的数据段或堆栈段的区别性。这对它而言都是虚拟内存
   空间所占用的不同地址范围。mmap是OS用来给进程提供的分配和管理这个3G虚拟空间的API。

2. loader

   loader在加载应用程序时，根据elf文件中的信息，使用mmap将应用程序的代码section，各个数据section（如bss）
   使用mmap保留elf文件中需要指定的虚拟空间的区域。注意，由于现代OS对物理内存的allocate on demand特性，此
   时保留虚拟空间的区域并不意味OS为你分配了相对应的物理内存。这个物理内存的分配只有在你从elf文件中拷贝数据到
   相应的虚拟内存区域中才会发生（此时硬件会产生缺页exception，exception handler会分配物理内存并建立虚拟到
   物理的映射）。另外你也可以使用mlockall()等让这种物理内存分配动作强制发生。

3. libc runtime中的malloc

    首先我想大家都明白，malloc是一个library function，而不是一个syscall API。malloc要做的事情就是处理进程被load
    后剩余的虚拟空间（当然不包括elf的entry之前的那部分小空间），malloc的处理是从低到高处理，从栈反方向增长。它也
　 使用mmap来保留自己需要的虚拟空间。但是malloc所分配的内存是受runtime library参数限制的。所以这就导致了堆和
   栈之间出现了一个巨大的"hole"。对于这个hole，只能使用mmap来分配。 当然，你可以更改library的参数来缩小这个
　 hole。

　引入malloc()有几个原因：
　 1) 让用户分配更小尺寸的内存块（mmap必须以PAGE为单位）
　 2) 提供一个比mmap更有效的内存使用和分配策略，比如buddy策略（或算法）。

正是如上所述，所以我认为，所有内存分配的根源都是mmap()。至于您所说的brk或sbrk，现在基本上已经被抛弃了，它们的
存在是由于"legency"，因为它所做的事情不需要从ＯＳ层面去实现，在runtime library里即可。

不当之处，欢迎大家指正!

panabit

原帖由 雨丝风片 于 2008-10-17 16:10 发表


当时讨论中使用的“mmap空间”只是对“文件内存映射和匿名内存区域”的一个形象描述，并非技术术语，
这个结合讨论上下文即可理解。



请参考：http://blog.chinaunix.net/u/9831/showart_110254.htm ...

"是否可以推论出：“应用程序”是通过“mmap”这个唯一的“API”来映射自己的数据段、代码段和堆栈的？"

------>对，应该是这样的。

雨丝风片

原帖由 panabit 于 2008-10-17 18:00 发表


有几个层面的东西需要分开：

1. OS层面

   在OS眼里，如果从内存管理角度看，它基本上不意识到某个程序的数据段或堆栈段的区别性。这对它而言都是虚拟内存
   空间所占用的不同地址范围。mmap是OS用 ...

实事求是的说，你上面这些话的绝大部分都是正确的，不过我困惑的是，你对我们的讨论的异议体现在哪里，或者说，
你把这么一大段论述放在这个讨论里的含义是什么。所以，我建议你从头到尾再仔细的阅读一下这个讨论的全过程中
每一个人的发言，弄明白这个讨论想要解决和解决了什么问题，以及这个讨论所基于的malloc的具体版本的实现方案，
至于其它的东西，至少在这个讨论里，我个人没有兴趣涉及。