每个用户空间进程都可以使用自己的2^47字节(128个TiB)虚拟地址空间。或者更多关于具有PML5支持的系统。
支持这些页面的可用物理RAM是物理RAM的总大小，减去大约30 MiB，内核需要自己的代码/数据。(不包括分页缓存: Linux将使用任何备用页作为缓冲区和磁盘缓存)。这主要与虚拟地址空间限制无关。
1G是内核消耗了多少虚拟地址空间。而不是有多少物理内存。
地址空间问题关系到单个进程可以同时使用多少内存，但是内核仍然可以使用所有的RAM来缓存文件数据等等。除非您发现下半个虚拟地址空间范围的2^(48-1)或2^(57-1)字节受到限制，否则不存在类似的问题。
有关x86-64虚拟内存映射，请参阅内核的文档/x86/x86-64/mm.txt。另外，为什么4级分页只能覆盖64 TiB的物理地址？ re: x86-64linux没有做一些不方便的HIGHMEM操作--整个虚拟地址空间的大部分都是为内核保留的，它映射了所有的内存，因为它是一个内核。
虚拟地址空间的使用确实间接地对内核可以使用多少物理内存设置了64 TiB的限制，但是如果没有这样的限制，就没有效果。就像32位内核不存在问题一样，如果机器的内存不足1或2 GiB的话。
内核实际保留的物理内存的数量取决于构建选项和模块，但可能大约是16到32 MiB.。
检查dmesg输出，并从我在旧的启动日志消息中找到的x86-64 5.16.3-arch1内核中寻找类似的内核日志消息。
代码语言：javascript运行复制Memory: 32538176K/33352340K available (14344K kernel code, 2040K rwdata, 8996K rodata, 1652K init, 4336K bss, 813904K reserved, 0K cma-reserved不要计算init (在引导后释放的)或reserved部件；我确信Linux并没有以一种使其无法用于任何其他用途的方式实际保留~800 MiB。
还可以查找后面的Freeing unused decrypted memory: 2036K / Freeing unused kernel image (initmem) memory: 1652K等(这与前面列出的init部件的大小相同，这就是不需要计算它的原因)。
它还可以在启动期间动态分配一些内存；初始的“内存”行只是它的.text、.data和.bss部分的总和，静态code+data大小。