我在使用具有大量 RAM 的 VirtualBox 和 VM 时遇到了严重的性能问题，已经在这个和那个其他问题中进行了更详细的解释。从我到目前为止的测试来看，与分配给 VM 的内存量有直接关系：问题发生在 48 GB 的 RAM 上，而不是只有 6 GB 或启用largepagesVM 的设置。
这很有趣，因为在Linux上默认情况下似乎没有启用该设置，文档只讲述了大约 5 % 的改进，并不是说在某些 RAM 大小下对于良好的性能根本没有必要，另外还有一些情况下VirtualBox 完全忽略largepages了。
00:00:42.866663 PGMR3PhysAllocateLargePage：分配大页面花费的时间太长（最后一次尝试 103 毫秒；nr 超时 11）；禁用
https://www.virtualbox.org/attachment/ticket/16518/VBox_16518_5112.log#L1154
因此，我试图深入研究该功能在 VirtualBox 的内存管理中实际发生了什么变化，并得出结论，它似乎实现了一种与操作系统的“巨页”相媲美的机制。这意味着在我看来，它不分配任何类型的“大页面”，也不分配transparent，hugetlb*而是仅从操作系统获取 4 kB 页面，将这些页面组合成 2 MB 的块，并在内部将其用作一个逻辑页面。
关于我的性能问题，这意味着（内存管理）性能的任何差异只能来自 VirtualBox 本身，而不是来自主机操作系统中的任何优化。OTOH，如果 VirtualBox 将实现类似于“大页面”的方法，它可能会解释为什么在我的案例中可以看到性能优势，就像其他使用操作系统中的“大页面”的软件一样，例如 viamadvise或其他。如果--largepages真的像我的情况那样产生如此巨大的差异，甚至可以说这是 VirtualBox 中的一个错误，不需要为 VM 中的一定数量的 RAM 设置该设置。
那么，我的假设是否正确，即 VirtualBox 仅使用操作系统中的普通 4 kB 页面而不是特殊的巨大页面？
VBox/VMM/VMMR0/PGMR0.cpp：
248 int rc = GMMR0AllocateLargePage(pGVM, pVM, idCpu, _2M,
249 &pVM->pgm.s.aLargeHandyPage[0].idPage,
250 &pVM->pgm.s.aLargeHandyPage[0].HCPhysGCPhys);
VBox/VMM/VMMR0/GMMR0.cpp：
3081 RTR0MEMOBJ hMemObj;
3082 rc = RTR0MemObjAllocPhysEx(&hMemObj, GMM_CHUNK_SIZE, NIL_RTHCPHYS, GMM_CHUNK_SIZE);
3083 if (RT_SUCCESS(rc))
VBox/运行时/r0drv/linux/memobj-r0drv-linux.c：
323 # ifdef VBOX_USE_INSERT_PAGE
324 paPages = alloc_pages(fFlagsLnx | __GFP_COMP | __GFP_NOWARN, rtR0MemObjLinuxOrder(cPages));
325 # else
326 paPages = alloc_pages(fFlagsLnx | __GFP_NOWARN, rtR0MemObjLinuxOrder(cPages));
327 # endif