似乎在 Windows 32 位上,内核会从总共 4G 的用户虚拟内存空间中预留 1G 的虚拟内存,并将部分内核空间映射到这 1G 空间中。
所以我的问题是:
- 在 32 位 Linux 上是否有类似的情况?
- 如果是这样,我们如何才能看到整个内存布局?
我认为
cat /proc/pid/map
只能看到某个进程的用户空间布局..
谢谢!
似乎在 Windows 32 位上,内核会从总共 4G 的用户虚拟内存空间中预留 1G 的虚拟内存,并将部分内核空间映射到这 1G 空间中。
所以我的问题是:
我认为
cat /proc/pid/map
只能看到某个进程的用户空间布局..
谢谢!
在 32 位 Linux 上是否有类似的情况?
是的。在 32 位 Linux 上,默认情况下,内核保留地址空间的高四分之一(从 C0000000 到内存顶部的 1G)供自己使用。
如果是这样,我们如何才能看到整个内存布局?
你不能。/proc/pid/maps
仅显示存在于用户空间中的映射。内核内存无法从用户空间应用程序访问,因此未显示。
请记住使用这种安排的原因 - 当内核处于活动状态时,它需要能够安装自己的映射,同时仍然保持用户空间映射处于活动状态(例如,它可以从用户空间复制数据或向用户空间复制数据)。它通过为自己保留高内存范围来实现这一点。
内核中内存映射的位置与内核本身无关,因此它根本不会暴露给用户空间,除非是偶然的,或者在某些调试消息中。
实际上,在 32 位 Windows 上,如果没有/3G
引导选项,内核会映射到线性地址空间的顶部 2GB,留出 2GB 给用户进程。
Linux 做了类似的事情,但是它将内核映射到线性空间的顶部 1GB,从而为用户进程留下 3GB。
我不知道您是否可以仅使用 /proc 文件系统来查看整个内存布局。对于我为学生设计的实验室,我创建了一个微型设备驱动程序,允许用户查看物理内存地址,并获取多个控制寄存器的内容,例如 CR3(目录页基地址)。
通过使用这两个操作,可以遍历当前进程(正在执行此操作的进程)的目录页面,查看存在哪些页面,哪些页面归用户和内核所有,或者仅归内核所有,哪些是读/写或只读等。有了这些信息,他们必须显示一个显示内存使用情况的地图,包括内核空间。
看看这个PDF。这是我们在课程中所做的所有实验的编译版本。 http://www.atc.us.es/asignaturas/tpbn/PracticasTPBN2011.pdf
在 PDF 的第 36 页(文档的第 30 页)上,您将看到内存映射的样子。这是在实验室 #3 中进行练习 #3.2 的结果。
文本是西班牙语的,但我相信如果有你无法理解的东西,你可以使用翻译器或类似的东西。本实验假设学生之前已经阅读过分页系统的工作原理以及如何解释目录和页面条目的布局。
地图是这样的。一个 16x64 块。块中的每个单元代表当前进程虚拟地址空间的 4MB。地图应该是三维的,因为有 4MB 区域由具有 1024 个条目(页面)的页表描述,并且并非所有页面都可能存在,但为了保持地图清晰,练习要求用户折叠这些区域,显示描述当前页面的第一个页面条目的内容,希望该页表中的所有后续页面共享相同的属性(这可能是也可能不是真的)。
此映射与内核 2.6.X 一起使用。其中PAE
未使用和PSE
使用(PAE
并且PSE
是来自控制寄存器的两个位字段CR4
)。PAE
启用 2MB 页面和PSE
启用 4MB 页面。4KB 页面始终可用。
. : PDE not present, or page table empty.
X : 4MB page, supervisor.
R : 4MB page, user, read only.
* : 4MB page, user, read/write.
x : Page table with at least one entry describing a supervisor page.
r : Page table with at least one entry describing an user page, read only.
+ : Page table with at least one entry describing an user page, read/write.
................................r...............................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
................................................................
...............................+..............................+.
xXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX..x...........................xx
可以看到有3GB的巨大内存空间,在这种情况下几乎是空的(进程只是一个小C应用程序,使用不到4MB,全部包含在一个页表中,其第一个当前页是只读页,假设是程序代码的一部分,或者可能是静态字符串)。
在 3GB 边界附近有两个读/写的小区域,可能属于用户程序加载的共享库。
最后 4 行(256 个目录条目)几乎都属于内核。实际存在和使用的条目有 224 个。这些映射了前 896MB 的物理内存,它是内核所在的空间。内核使用最后 32 个条目来访问具有超过 896MB RAM 的系统中超过 896MB 标记的物理内存。