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毫秒; nr超时11）; DISABLE

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

因此，我试图深入研究VirtualBox的内存管理中该功能的实际变化，并得出结论，它似乎实现了一个可与“＃34;巨大页面”相媲美的机制。它自己的操作系统。这意味着在我看来它并没有分配＆＃34;巨大的页面＆＃34;任何类型，transparent和hugetlb*，但只从OS获取4 kB页面，将这些页面组合在一个2 MB的块中，并在内部将其用作one logical page。

关于我的性能问题，这意味着（内存管理）性能的任何差异只能来自VirtualBox本身，而不是来自主机操作系统中的任何优化。 OTOH，如果VirtualBox实现类似于＆＃34;大页面＆＃34;的方法，它可以解释为什么在我的情况下可以看到性能优势，就像使用＆＃34;巨大页面＆＃34;来自OS，例如通过madvise或其他。如果--largepages真的像我的情况那样产生如此巨大的差异，那么甚至可以说它是VirtualBox中的一个错误，不需要在虚拟机中设置一些RAM。

那么，我的假设是正确的，VirtualBox只使用来自操作系统的普通4 kB页面而不是特别大的页面吗？

垂直框/ 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);

垂直框/ VMM / VMMR0 / GMMR0.cpp：

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

垂直框/运行时间/ 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

Answer 1

通过查看VirtualBox的来源（截至2019年11月），我得出的结论是 VirtualBox在任何主机操作系统中都没有大页面支持，但Solaris ：memobj-r0drv-solaris.c是唯一这样的例子。

VirtualBox是否分配了OS特殊的＆＃34;巨大的页面＆＃34;？

1 个答案: