作者tinlans ( )
看板C_and_CPP
标题Re: [问题] memory stack 的问题
时间Mon Aug 29 13:36:39 2016
※ 引述《kyuudonut (善良老百姓)》之铭言：
: 最近在研读virtual memory相关知识，大致上了解paging的运作模式
: [问题二] 如果有多个 process 同时运作，各自 stack 的起始位置又是如何分配呢？
: (一直往下长不会撞到吗@@)
: (当某 process 需要的 stack 大小超过两个 page 又是如何维护?
: page 如果不连续怎麽办?)
你既然是在读 virtual memeory，应该知道每个 process 都有自己一块虚拟位址空间。
以 32-bit 系统来说，就是每个 process 各自有 4GB 的定址空间。
这 4GB 的定址空间，再细一点的分法是再区分成 user space 跟 kernel space。
预设的状况下，Windows 是 2GB/2GB，Linux 则是 3GB/1GB。
有些人在 32-bit 的 XP 插了很大记忆体的显示卡，结果记忆体剩下 2.xx GB，
原因就是这样来的，因为 kernel space 要划一块去映射，细节要问熟微软系统的。
stack 和 heap 这些东西都在 user space，user space 是各 process 之间独立的。
换句话说对每个 32-bit Linux process 而言，那 3GB 里不会有其它 process 的资料。
所以没有什麽撞到的问题，两个平行世界的东西你要怎麽让它们相撞？
如果要 programmer 去担心这种事，那 virtual memory 存在的意义就没有了。
你没特别设定的话，同个编译系统生出来的执行档，在同个 OS 执行，
每个 process 的 stack 起始位址都是一模一样的，当然这不会是实体位址。
stack 的 page 当然是连续的。
在每个 process 各自独立的虚拟 3GB 定址空间里，有什麽理由划不出连续空间？
你 C 程式里 pointer 看到的记忆体位址都是这些虚拟位址，并不是实体的。
至於这些 page 怎麽对应到实体记忆体的 frame，我想书上应该都写得很清楚了。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.132.55.117
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1472449011.A.2A3.html
※ 编辑: tinlans (220.132.55.117), 08/29/2016 13:48:13
1F：→ tjjh89017: 你没有假设ASLR disable的情况 08/29 16:53
2F：→ tjjh89017: 不能说「stack 起始位址都是一模一样的」 08/29 16:53
3F：→ tinlans: 确实现在的系统 ASLR 预设都打开了，但会把他的问题更 08/29 21:14
4F：→ tinlans: 复杂化。不过还是感谢补充 XD 08/29 21:14
5F：推 wtchen: 请问个问题，32bit一个process就4GB，64bit应该就unlimit 08/29 23:15
6F：→ wtchen: 那系统要怎麽判断有无out-of-memory? 08/29 23:16
我知道的部分是有点老了，而且是 BSD malloc 的实作，因为我是 FreeBSD 派的。
不过还是能大概回一下你的问题，因为概念基本上都通。
这 4GB 空间不是你 pointer 随便玩都行，还是有它的规矩在。
OS 课本上写的记忆体保护原理实际上也有作用，所以你没跟 OS 申请依然是非法存取。
BSD libc 会知道目前 heap size，如果 process 呼叫 malloc() 时，
如果 heap 必须长大才能满足需求，必须呼叫 sbrk() 这个 system call。
这个 system call 如果 return -1 表示失败，因此 OS 可以在这里拒绝配置记忆体。
sbrk() 做的事情是移动 data segment 的 break 位址，break 的意义手册上查得到：
The brk() and sbrk() functions are used to change the amount of memory
allocated in a process's data segment. They do this by moving the loca-
tion of the "break". The break is the first address after the end of the
process's uninitialized data segment (also known as the "BSS").
简单来说，把 break 往高位址移动就是给这 process 更多 memory 的意思。
OS 没有 heap 的概念，它把 data + heap 当成一个 data segment 整体。
如果你随便把 sbrk 这关键字丢 Google 图片搜寻，应该会看到这种图：
http://flylib.com/books/2/830/1/html/2/images/09fig9_3.jpg
使用 sbrk() 要求更多记忆体，就等同於把 break 上推，也等於 heap 往上长大。
如果没推上去就摸更上面的记忆体，下场大家也很熟悉，就是 segmentation fault。
某一年开始 FreeBSD 的手册加入了这两行：
The brk() and sbrk() functions are legacy interfaces from before the
advent of modern virtual memory management.
之後 POSIX.1-2001 也把 brk() 跟 sbrk() 移除了，所以我说我知道的有点老。
後来我的志向不是做 OS，所以也没有再重新 trace 相关细节过了。
总之这是个相当古老的东西，从 Version 7 AT&T UNIX 时代开始一路继承下来的。
现在的做法我不知道，等专攻 OS 的进来补充。
7F：推 suhorng: 4GB 是 memory address space, 要用记忆体要配置才有 08/29 23:40
8F：→ suhorng: 作业系统管理记忆体的分配跟 mapping, 会知道有没有 OOM 08/29 23:42
9F：→ ah7675: address space跟使用多少是两回事啊啊啊 08/29 23:43
10F：推 lsc36: 指标有32/64bit这麽长可是还是要跟OS拿page来用啊 08/29 23:45
11F：推 kyuudonut: 谢谢前辈回答，所以kernel在切换process的时候，会再 08/30 00:21
12F：→ kyuudonut: 依另外依各自的page table做映射的意思吗? 08/30 00:22
以前常见的一种实作就是把 page table 起始位址存在 PTBR 这个暂存器，
所以会随着 context switch 一起被储存和恢复，因此自然会选到正确的那张。
这个技巧应该已经老到写进课本蛮久了，你应该会有印象才对。
※ 编辑: tinlans (220.132.55.117), 08/30/2016 01:37:45
13F：推 wtchen: 那请问一个process里的不同thread的stack要怎麽划？ 08/30 01:09
14F：→ wtchen: 据我所知Linux预设的stack size limit是8MiB 08/30 01:11
15F：→ wtchen: 远小於user space的3GB... 08/30 01:11
16F：推 wtchen: 其实我很不懂heap是往下延伸stack往上直到两者相撞的话 08/30 01:16
17F：→ wtchen: 为啥heap还是可以无限增加(看OS支援大小)而stack不行 08/30 01:17
如果你有把原 po 说的那本书看完，你应该会知道 stack 和 heap 中间还有夹其它东西。
简单 Google 一下的话可以发现像这样的图：
http://static.duartes.org/img/blogPosts/linuxFlexibleAddressSpaceLayout.png
如果你两边都能在 runtime 往中间无限推，那麽做 OS 的人应该会很头痛。
还好大部分的 programmer 都被教育成不要滥用 stack 空间，所以没什麽大问题。
实际上一般应用程式，包括 MySQL 和 nginx 在内，stack 空间的需求都比你想像得小。
18F：→ PkmX: linux的话thread的stack是userspace自己allocate然後pass给 08/30 02:03
19F：→ PkmX: clone(2) 08/30 02:03
20F：→ PkmX: 8MB是预设的softlimit 你爽的话也可以ulimit -s去加大它 08/30 02:06
※ 编辑: tinlans (220.132.55.117), 08/30/2016 02:12:46
21F：→ PkmX: 其实我很讨厌往上/下长的说法 说往0或无限大长不是很好吗XD 08/30 02:09
22F：→ kdjf: stack也可以无限加，只是OS申请 08/30 02:10
runtime 增加的方法我就真的没听过了，时代真进步。是哪个 system call？
23F：→ kdjf: 要先跟OS申请 08/30 02:11
24F：→ kdjf: heap要用brk跟系统要空间一样 08/30 02:12
25F：推 wtchen: 感谢说明，受教了 08/30 02:13
26F：→ kdjf: 只是习惯上把已知一定连续又可预测生命的资料放在自然连续的 08/30 02:13
27F：→ kdjf: stack里方便又快 08/30 02:14
※ 编辑: tinlans (220.132.55.117), 08/30/2016 02:15:54
28F：推 kdjf: 刚刚google到setrlimit,可能是他吧 08/30 02:17
29F：→ kdjf: 不过stack叫做stack&他的用法可能是古老的hardware stack 08/30 02:19
30F：→ kdjf: 时留下来的? 08/30 02:19
确实是它，虽然我一直都知道这个 system call 的存在，
不过一直以为只有在 execve() 被呼叫的当下会去看而已。
刚才查了一下，至少确定它在 BSD 家族可以在 runtime 调整 stack size。
因为长期在做 compiler 这块，记忆渐渐被窜改成在 linker 指定是最後的机会 XD
31F：→ tjjh89017: 是说，64bit还有实体定址的问题，不是真的一定有2^64 08/30 02:24
※ 编辑: tinlans (220.132.55.117), 08/30/2016 03:06:31
32F：→ kyuudonut: 谢谢前辈指点! 难怪每次看到memory的记忆体分配图 08/30 15:21
33F：→ kyuudonut: 有些都会称为 process memory 08/30 15:21
34F：推 CaptainH: 推 08/30 22:38
35F：推 askacis: linux下setrlimit()也是可以用来调Stack size 08/31 18:19
36F：→ askacis: pthread_attr_setstacksize()可以拿来调整thread 08/31 18:20