我试图使用pmap -x
命令在Linux x86-64上查看进程的内存映射.看着pmap的输出我很困惑.特别是对于映射动态库的条目.它们有多个条目(实际上它们全部为4个,其中一些条目有3个条目).以下是一个例子
Address Kbytes RSS Dirty Mode Mapping
00000036ca200000 88 64 0 r-x-- libpthread-2.5.so
00000036ca216000 2044 0 0 ----- libpthread-2.5.so
00000036ca415000 4 4 4 r---- libpthread-2.5.so
00000036ca416000 4 4 4 rw--- libpthread-2.5.so
Run Code Online (Sandbox Code Playgroud)
每个库的第二行总是大小为2MB,而没有页面权限.在所有图书馆中,似乎它的RSS始终为零.最后两行也具有相同的大小(基页大小)和相同的权限(少数库没有rw映射).
有人对此有一些解释吗?我有点意识到,带有只读保护的映射可能由加载器完成,以读取库的元数据,而具有可执行权限的部分实际上是库的代码.我可能错了.
但我对这一中间行没有任何线索.没有许可,没有用法?谁在这里有一些智慧的话?
我还看到有几页报告在匿名内存上,没有任何模式位设置.这些代表什么?
Linux on x86-64是否支持多个巨大的页面大小(例如,超过4KB基页大小的2MB和1GB页面大小)?如果是,是否有办法为给定的分配指定使用哪个巨大的页面大小?换句话说,我的问题是,如果使用"MAP_HUGETLB"标志mmap()
,它将它们分配映射到默认大小的大页面.无论如何要求将分配映射到非默认的巨页大小?
我想估计由于运行Linux的x86-64(Intel Nehalem)机器上的TLB未命中而导致的性能开销.我希望通过使用一些性能计数器得到这个估计.有没有人对什么是估计这个的最佳方法有一些指示?
谢谢Arka
Linux的x86-64用户虚拟地址空间为47位.这实际上意味着Linux可以映射具有大约~128 TB虚拟地址范围的进程.
然而,让我感到困惑的是x86-64架构支持每个进程的ISA定义的4级分层页表(排列为基数树).页表的根目录最多只能映射512 GB的连续虚拟地址空间.那么Linux如何支持512GB以上的虚拟地址范围呢?它是否为每个进程使用多个页表?如果是,那么对于一个进程,CR3(x86-64的寄存器包含页表基址的地址)应包含哪个给定进程?我错过了什么吗?
Transparent Huge Pages(THP)
最近Linux内核中的支持允许在不同页面大小之间自动升级/降级(例如,x86-64中的4KB和2MB).但我不确定THP是否也可以促进/降低页面大小4KB
和1GB
页面之间2MB
或1GB
页面之间的页面大小.
有人可以对此发表评论吗?
我在Linux x86-64系统上运行.从Python(2.6)脚本,我希望定期检查给定的进程(由pid标识)是否已成为"defunct"/ zombie(这意味着进程表中的条目存在但进程无效).知道进程消耗多少CPU也是一件好事(类似于'top'命令所显示的).
有人可以给我一些关于如何在Python中获取这些内容的指示吗?
x86/x86-64公开了MTRR(存储器类型范围寄存器),它可用于为不同的用途指定物理地址空间的不同部分(例如,可Cacheable,Unchangeable,Writecombining等).
我的问题是,是否有人知道这些受MTRR定义的物理地址空间的限制是如何在硬件中实施的?在每次内存访问时,硬件检查物理地址是否落在给定范围内,然后进程决定是查找缓存还是查找writecombining缓冲区或直接将其发送到内存控制器?
谢谢
我想知道Linux(x86-64)中是否有任何实用程序/代码可以转储给定进程(用户)地址空间的每个页表项?
谢谢