Chinaunix

标题: 用户态地址空间页目录表是如何建立的? [打印本页]

作者: cljj0322    时间: 2012-09-28 14:09
标题: 用户态地址空间页目录表是如何建立的?
   进程切换必须切换相应的进程页目录表到cr3;线性地址到物理的地址的映射依赖于页目录表;知道页目录表和1个线性地址,就能访问相应的物理地址。
  问题是:
  1 页目录表是如何建立的呢?建立的时机、依据呢?是在cpu将磁盘可文件拷贝至内存时,依赖于缺页异常实现的吗?
  2 引申问题:线性区中的代码段、数据段属于静态内存;堆栈段属于动态内存。可否这样理解:动态内存是可以被放入交换区的;而静态内存是一直驻留在物理内存中,除非进程退出,否则会一直占用这段内存?
   

作者: 瀚海书香    时间: 2012-09-28 17:46
回复 1# cljj0322
进程切换必须切换相应的进程页目录表到cr3;线性地址到物理的地址的映射依赖于页目录表;知道页目录表和1个线性地址,就能访问相应的物理地址。
  问题是:
  1 页目录表是如何建立的呢?建立的时机、依据呢?是在cpu将磁盘可文件拷贝至内存时,依赖于缺页异常实现的吗?
  2 引申问题:线性区中的代码段、数据段属于静态内存;堆栈段属于动态内存。可否这样理解:动态内存是可以被放入交换区的;而静态内存是一直驻留在物理内存中,除非进程退出,否则会一直占用这段内存?


内核缺页异常的时候,建立的页表。

   
作者: captivated    时间: 2012-09-29 19:52
嗯嗯...

斑竹就是斑竹啊。
再引申一下,

1. 所以当一个新进程建立时,只要分配一个页目录就可以了,映射关系可以暂时不用设置。
然后读取可执行文件,开始加载程序,这时就开始依赖缺页异常了。当加载完最初需要的代码段和数据段,程序可以执行了,操作系统将PC指向可执行程序的入口,设置好运行时栈起始点,开始执行。然后就是缺页异常不断发生,缺页异常不断被处理的过程......

2. 虚拟地址空间中的一段属性相同并且地址连续的区域称之为一个VMA(Virtual Memory Area, 注意不是Virtual Memory Address那个VMA, 当然它们确实都叫VMA...), 这个VMA当然是内核里面的一个管理概念, 体现为内核代码里的一个数据结构。一个VMA可能映射至一个或者多个物理Page. 代码段数据段会不会换出和进程的“静态存储 动态存储”概念几乎没什么关系,只要内核的换页对于进程是透明的(嗯,实际上它们就是透明的),换哪个区域都不会有影响 -- 换了又怎么样?只要内核想换或者认为需要换 -- 进程需要时还可以换回来。对于进程来说,把“静态存储区域”理解为是一段死的一直存在在虚拟内存空间中的指令/代码总是没有问题的 -- 因为换页是透明的。所以,所谓“静态/动态内存”是一个从进程的虚拟空间角度去考察的概念,主要是看内存区域会不会动态伸缩/增减,内核是不用管的。


以上。本人理解有限,如有误,砖轻拍,谢谢。
作者: cdtits    时间: 2012-09-29 20:44
偷偷琢磨一下....
作者: cljj0322    时间: 2012-10-08 09:44
《Linux操作系统原理及应用》
                  --陈莉君
6.6.1 交换的基本原理

哪种页面被换出

实际上,交换的最终目的是页面的回收。并非内存中的所有页面都是可以交换出去的。事实上,只有与用户空间建立了映射关系的物理页面才会被换出去,而内核空间中内核所占的页面则常驻内存。我们下面对用户空间中的页面和内核空间中的页面给出进一步的分类讨论。

  可以把用户空间中的页面按其内容和性质分为以下几种:

(1)   进程映像所占的页面,包括进程的代码段、数据段、堆栈段以及动态分配的“存储堆”(参见图6.13)。

(2)   通过系统调用mmap()把文件的内容映射到用户空间

(3)   进程间共享内存区

  对于第1种情况,进程的代码段数据段所占的内存页面可以被换入换出,但堆栈所占的页面一般不被换出,因为这样可以简化内核的设计。

   对于第2种情况,这些页面所使用的交换区就是被映射的文件本身。

   对于第3种情况,其页面的换入换出比较复杂。


与此相对照,映射到内核空间中的页面都不会被换出。具体来说,内核代码和内核中的全局量所占的内存页面既不需要分配(启动时被装入),也不会被释放,这部分空间是静态的。(相比之下,进程的代码段和全局量都在用户空间,所占的内存页面都是动态的,使用前要经过分配,最后都会被释放,中途可能被换出而回收后另行分配)







欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2