即使主要使用了48位地址，地址空间对于X86-64还是很大的。
在X86 32位机器上，很清楚内核占用了多少RAM。通常， Zone_Normal 的1 GB大约在内存的底部，而物理（不是虚拟）地址中1GB上方的所有内容均用于 Zone_HighMem （用于用户空间）。这将是3：1分。当然，如果我们可以拥有1：3、2：2等，我们可以使用配置。（通过更改 vm_split ）。
RAM中的内核空间中有多少内存，用于64位内核？
我知道 page_offset 设置为远高于x64中物理上可寻址的内存的值（对于48和56 ）。 page_offset x64中仅描述了虚拟地址空间中的拆分，而不是物理（48位 page_offset 将为 ffff8888800000000000 ）。
那么1 GB的内存内核空间吗？ 2GB？ 3？是否存在描述大小的变量或宏？是计算的吗？
The address space is huge for the x86-64 even though 48-bit addresses are mainly used.
On x86 32-bit machines it was pretty clear how much RAM the kernel took up. Generally around 1 GB of ZONE_NORMAL is on the bottom of memory while everything else above the 1GB in PHYSICAL (not virtual) addresses were for ZONE_HIGHMEM (for user space). This would be a 3:1 split. Of course we can have configurations were we can have a 1:3, 2:2, etc. (by changing VM_SPLIT).
How much memory in RAM is for kernel space for 64 bit kernels?
I know the PAGE_OFFSET is set to a value far above physically addressable memory in x64 (for both 48 and 56). PAGE_OFFSET in x64 just describes the split in virtual address space, not physical (a 48 bit PAGE_OFFSET would be ffff888000000000 ).
So does 1 GB of memory house kernel space? 2GB? 3? Are there variable or macros that describe the size? Is it calculated?
发布评论
评论（2）
每个用户空间过程都可以使用自己的2^47字节（128 TIB）虚拟地址空间。在具有PML5支持的系统上或更多。
可用的物理RAM支持这些页面是物理RAM的总尺寸，减去30 MIB左右，以便内核需要其自己的代码/数据。 （不包括PageCache：Linux将使用任何备用页面作为缓冲区和磁盘缓存）。这主要与虚拟地址空间限制无关。
1G是 virtual 地址内核所用的空间。不是多少物理公羊。
地址空间问题对于单个进程可以同时使用多少内存很重要，但是内核仍然可以将所有RAM用于缓存文件数据等。除非您找到
2^（48-- 1）或2^（57-1）the the Firtual Adveress空间范围的字节狭窄，没有等效问题。请参阅内核的对于X86-64虚拟内存图。另外为什么4-级分页只能覆盖64个物理地址的64个tib tib re：x86-64 linux不做不便的高级事物 - 整个工作一半的虚拟地址空间是为内核保留的，并且它映射为 the ram，因为它是一个内核。
虚拟地址空间使用情况确实间接设定了64个TIB限制内核可以使用的物理RAM，但是如果您没有效果少。就像如果您的机器少于1或2 GIB的RAM，那么32位内核也不是问题。
内核实际保留的物理RAM量取决于构建选项和模块，但可能是16至32 MIB
。内核日志消息来自x86-64 5.16.3-ark1内核，我在旧的boot-log消息中找到。
不要计算
init（启动后释放）或保留parts;我敢肯定，Linux实际上不会以一种使其无法使用的方式保留〜800 MIB。另外，请查找以后的
释放未使用的解密内存：2036K/释放未使用的内核映像（initmem）内存：1652K等（这与init /代码>前面列出的部分，这就是为什么您不必计算它。）它也可能在启动过程中动态分配一些内存；那个初始的“内存”行只是其
.text，.data和.bss部分，静态代码+数据大小的总和。Each user-space process can use its own 2^47 bytes (128 TiB) of virtual address space. Or more on a system with PML5 support.
The available physical RAM to back those pages is the total size of physical RAM, minus maybe 30 MiB or so that the kernel needs for its own code/data. (Not including the pagecache: Linux will use any spare pages as buffers and disk cache). This is mostly unrelated to virtual address-space limits.
1G is how much virtual address space a kernel used up. Not how much physical RAM.
The address-space question mattered for how much memory a single process could use at the same time, but the kernel can still use all your RAM for caching file data, etc. Unless you're finding the
2^(48-1)or2^(57-1)bytes of the low half virtual address-space range cramped, there's no equivalent problem.See the kernel's Documentation/x86/x86-64/mm.txt for the x86-64 virtual memory map. Also Why 4-level paging can only cover 64 TiB of physical address re: x86-64 Linux not doing inconvenient HIGHMEM stuff - the entire high half of virtual address space is reserved for the kernel, and it maps all the RAM because it's a kernel.
Virtual address space usage does indirectly set a 64 TiB limit on how much physical RAM the kernel can use, but if you have less than that there's no effect. Just like how a 32-bit kernel wasn't a problem if your machine had less than 1 or 2 GiB of RAM.
The amount of physical RAM actually reserved by the kernel depends on build options and modules, but might be something like 16 to 32 MiB.
Check
dmesgoutput and look for something like this kernel log message from an x86-64 5.16.3-arch1 kernel I found in an old boot-log message.Don't count the
init(freed in after boot) orreservedparts; I'm pretty sure Linux doesn't actually reserve ~800 MiB in a way that makes it unusable for anything else.Also look for the later
Freeing unused decrypted memory: 2036K/Freeing unused kernel image (initmem) memory: 1652Ketc. (That's the same size as theinitpart listed earlier, which is why you don't have to count it.)It might also dynamically allocate some memory during startup; that initial "memory" line is just the sum of its
.text,.data, and.bsssections, static code+data sizes.在64位系统上，唯一的限制是内核可以使用多少物理内存。内核将映射所有可用的RAM，用户空间应用程序应该能够访问内核所能提供的尽可能多的访问权限，同时保持内核可以运行。
On 64-Bit systems, the only limitation is on how much physical memory the kernel can use. The kernel will map all the available ram, and user space applications should be able to gain access to as much as the kernel can provide while maintaining sufficient for the kernel to operate.