pmap -d 不显示物理内存占用，仅补充Device、Offset、Inode等映射元数据；真实物理占用需用pmap -x（看RSS）或/proc/PID/smaps（含Rss、Pss等细粒度指标）。
pmap -d 并不显示“数据段的真实物理占用详情”，它只补充设备号、文件偏移等元数据，不提供 RSS、PSS 或实际物理页统计。
为什么 pmap -d 不能看物理内存占用
pmap -d 的作用是增强映射来源的可追溯性，输出中新增三列：Device（主次设备号）、Offset（文件内偏移）、Inode。它帮你确认某段内存是否来自磁盘文件（如 /bin/bash）、tmpfs（00:15）、还是纯匿名区（Device=00:00）。但它完全不包含任何物理内存指标——没有 RSS、没有 Dirty、也没有页驻留状态。
所谓“数据段”（.data）在 ELF 中属于可执行文件的一部分，通常和 .text 合并在同一段映射里（如 /usr/bin/python3），pmap -d 能告诉你它映射自哪个 inode、从文件哪一偏移开始，但无法告诉你当前有多少页被加载进 RAM、是否被修改过。
要看真实物理占用，必须用 -x 或 -XX
真正反映物理内存使用的是 RSS（Resident Set Size），单位 KB，代表该段当前实际驻留在 RAM 中的物理页数。获取方式只有：
- pmap -x PID：输出含 Address、Kbytes、RSS、Dirty、Mode、Mapping 六列，其中 RSS 就是每段的物理内存占用；最后一行 total 的 RSS 总和 ≈ ps 的 RSS 值
- pmap -XX PID（需内核开启 CONFIG_PROC_PAGE_MONITOR）：进一步区分 anon/file/shared 页类型，并显示 huge page 使用情况
例如，若想确认 libc.so.6 的 .data 部分是否大量驻留内存，应运行：
pmap -x 12345 | grep "libc\.so\.6"，观察其 RSS 值——而不是用 -d。
数据段在 pmap 输出中通常不单独标识
ELF 的 .data 段不会以 [data] 形式出现在 Mapping 列。它一般混在共享库或可执行文件的主映射行中，权限多为 r--p（只读数据）或 rw-p（可读写数据），可通过 Mode 列辅助识别：
- r-xp → 通常是 .text（代码）
- rw-p → 很可能是 .data 或 .bss（已初始化/未初始化数据）
- r--p → 常见于只读数据段（如字符串常量池）
所以判断数据段物理占用，要结合 Mapping（是否为 .so/.exe）、Mode（是否 rw-p/r--p）、以及 RSS 值三者交叉验证，而非依赖某个固定标签。
更准的替代方案：直接读 /proc/PID/smaps
如果需要比 pmap -x 更细粒度的数据段分析（比如区分 anon vs file-backed、私有 vs 共享、clean vs dirty 页），应查看原始数据源：
- awk '/^Rss:/ {sum += $2} END {print sum " kB"}' /proc/12345/smaps —— 获取总 RSS
- grep -A1 -B1 "libc\.so\.6" /proc/12345/smaps | grep -E "^(Rss|Size|MMUPageSize):" —— 查看该库各页类型分布
- smaps 中的 Pss 比 RSS 更公平地体现数据段的实际内存成本（按共享比例分摊）
