VirtualBox是否分配操作系统专用的“大页面”？

Question

我在使用带有大量RAM的VirtualBox和VM时遇到严重的性能问题，在this和that其他问题中已有更详细的说明。从到目前为止的测试来看，与分配给VM的内存量有直接关系：48 GB的RAM会出现问题，而只有6 GB或启用VM的设置largepages时不会出现问题。

这很有趣，因为默认情况下Linux上似乎未启用该设置，the docs仅可提高约5％，对于在某些RAM大小下获得不错的性能根本没有必要，此外在某些情况下，largepages总计为ignored by VirtualBox。

00：00：42.866663 PGMR3PhysAllocateLargePage：分配大页面花费的时间太长（上一次尝试时间为103毫秒；超时值为11）；禁用

https://www.virtualbox.org/attachment/ticket/16518/VBox_16518_5112.log#L1154

因此，我试图深入研究该功能在VirtualBox的内存管理中实际发生了什么变化，并得出的结论是，它似乎实现了一种与操作系统本身的“大页面”相当的机制。我认为这意味着它不会分配任何类型的“大页面”，既不是transparent也不是hugetlb*，而是仅从OS中获取4 kB页面，将它们合并为2 MB的块并将其用作[ C0]内部。

关于我的性能问题，这意味着（内存管理）性能的任何差异都只能来自VirtualBox本身，而不能来自主机OS中的任何优化。 OTOH，如果VirtualBox将实施类似于“大页面”的方法，则可能可以解释为什么在我看来完全可以看到性能优势，例如使用OS中其他使用“大页面”的软件一样。通过one logical page或其他方式。如果madvise确实像我的情况那样产生了巨大的变化，甚至有人可能会认为这是VirtualBox中的错误，不需要在VM中为RAM设置一定数量。

所以，我的假设是正确的，VirtualBox仅使用来自操作系统的普通4 kB页面，而不是特殊的大页面？

VBox / VMM / VMMR0 / PGMR0.cpp：

--largepages

VBox / VMM / VMMR0 / GMMR0.cpp：

248     int rc = GMMR0AllocateLargePage(pGVM, pVM, idCpu, _2M,
249                                     &pVM->pgm.s.aLargeHandyPage[0].idPage,
250                                     &pVM->pgm.s.aLargeHandyPage[0].HCPhysGCPhys);

VBox / Runtime / r0drv / linux / memobj-r0drv-linux.c：

3081            RTR0MEMOBJ hMemObj;
3082            rc = RTR0MemObjAllocPhysEx(&hMemObj, GMM_CHUNK_SIZE, NIL_RTHCPHYS, GMM_CHUNK_SIZE);
3083            if (RT_SUCCESS(rc))

Answer 1

通过查看截至2019年11月的VirtualBox的来源，我得出的结论是VirtualBox在任何主机OS中均不支持大页面但是Solaris：

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

是唯一这样的示例。