Centos Hugepagesize在VM中没有增加到1G

我正在ESXi服务器中使用CentOS虚拟机。我想将巨大的页面大小增加到1G

我点击了链接：

我执行了小脚本以检查是否支持1 GB的大小：

[root@localhost ~]# if grep pdpe1gb /proc/cpuinfo >/dev/null 2>&1; then echo "1GB supported."; fi
1GB supported.
[root@localhost ~]# 

我在/etc/default/grub中添加了

default\u hugepagesz=1GB hugepagesz=1G hugepages=4

grub2 mkconfig-o/boot/grub2/grub.cfg

重新启动虚拟机

但我仍然可以看到2048KB（2MB）的巨大页面大小

[root@localhost ~]# cat /proc/meminfo | grep -i huge
AnonHugePages:      8192 kB
HugePages_Total:    1024
HugePages_Free:     1024
HugePages_Rsvd:        0
HugePages_Surp:        0
**Hugepagesize:       2048 kB**
[root@localhost ~]# 

以下是VM的详细信息：

[root@localhost ~]# uname -a
Linux localhost.localdomain 3.10.0-514.10.2.el7.x86_64 #1 SMP Fri Mar 3 00:04:05 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]#

[root@localhost ~]# cat /proc/cpuinfo  | grep -i flags
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi ept vpid
flags       : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts nopl xtopology tsc_reliable nonstop_tsc aperfmperf pni pclmulqdq vmx ssse3 cx16 pcid sse4_1 sse4_2 x2apic popcnt aes xsave avx hypervisor lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi ept vpid
[root@localhost ~]# 

---

8GB内存和2个CPU分配给VM。

1gb hugepage支持的CPU标志和来宾操作系统支持/启用不足以让1gb hugepage在虚拟化环境中工作

在PMD（在PAE和x86_64之前为2MB或4MB）和PUD级别（1GB）上创建巨大页面的想法是创建从大尺寸的对齐虚拟区域到物理内存的某个大区域的映射（据我所知，它也应该对齐）。通过虚拟机监控程序的附加虚拟化级别，现在有三个（或四个）内存级别：来宾操作系统中应用程序的虚拟内存、一些被来宾操作系统视为物理的内存（它是由虚拟化解决方案管理的内存：ESXi、Xen、KVM等）和实际物理内存。我们可以合理地假设hugepage idea在所有三个级别上都应该有相同大小的大区域才有用（生成更少的TLB未命中率，使用更少的页表结构来描述大量内存-grep“需要大于4KB的页”在内存中）

所以，要在来宾操作系统中使用某种级别的巨大页面，您应该在物理内存（在您的主机操作系统中）和虚拟化解决方案中已经有相同大小的巨大页面如果主机操作系统和虚拟化软件无法使用Guest中的巨大页面，则无法有效地使用它们。（一些像qemu或bochs可能会模仿它们，但这将是从慢到非常慢。）当您同时需要2MB和1GB的巨大页面时：您的CPU、主机操作系统、虚拟系统和来宾操作系统都应该支持它们（主机系统应该有足够的对齐的连续物理内存来分配1GB的页面，您可能无法在NUMA中通过几个套接字拆分此页面）

不知道ESXi，但有一些链接

• RedHat和一些（？）linux虚拟化解决方案（使用libvirtd）。在“虚拟化调优和优化指南”中，列出了主机操作系统的手动hugepages:：

步骤8.2.在启动时分配1 GB大页面

要在启动时分配不同大小的大页面，请使用以下命令，指定大页面的数量。此示例分配4 1 GB大页面和1024 2 MB大页面：“

default\u hugepagesz=1G hugepages=1G hugepages=4 hugepages=2M hugepages=1024

”更改此命令行以指定不同数量的大页面在开机时被分配

注意：在引导时第一次分配1GB的大页面时，还必须完成接下来的两个步骤

在主机上装载2 MB和1 GB的大型页面：

#mkdir/dev/hugepages1G #mount-t hugetlbfs-o pagesize=1G无/dev/hugepages1G #mkdir/dev/hugepages2M #mount-t hugetlbfs-o页面大小=2M无/dev/hugepages2M

重新启动libvirtd，以便在来宾上使用1 GB的大型页面：

#服务重启libvirtd

客人现在可以使用1GB的大页面

• 对于Ubuntu和KVM：

通过增加页面大小，可以减少页面表并减少TLB缓存上的压力….

vm.nr_hugepages=256

…重新启动系统（注意：这是关于主机和主机操作系统的物理重新启动）…将Libvirt设置为使用大页面

KVM_hugepages=1

…将来宾设置为使用大页面

• 对于Fedora和KVM（旧手册约2MB页）：

• ESXi 5支持2MB页面，应手动启用：

• 对于未知版本的“VMware ESX server”，从2015年3月起，论文：BQ Pham，：

缺乏对大型页面的虚拟机监控程序支持：最后，虚拟机监控程序供应商在完全采用大型页面之前可能需要几个生产周期。例如，VMware的ESX server目前在虚拟机监控程序中不支持1GB大型页面， 即使x86-64系统上的来宾可以使用它们

• 更新的论文，没有关于1GB页面的直接结论：

我们发现，跨体系结构（如ARM、x86-64）和基于容器的技术的一系列虚拟机监控程序（如ESX、KVM）的大型页面与轻量级内存管理存在冲突

• 来自VMWare的旧pdf：“大页面性能。ESX Server 3.5和ESX Server 3i v3.5”-仅支持2MB大页面

VMware ESX Server 3.5和VMware ESX Server 3i v3.5为虚拟化应用程序引入了2MB大页面支持 在早期版本的ESX Server中，来宾操作系统的大页面是使用小页面模拟的 这意味着，即使来宾操作系统使用大页面，它也无法获得 减少TLB未命中的性能优势。ESX Server 3.5和ESX中增强的大页面支持 服务器3i v3.5支持PAE模式下的32位虚拟机和64位虚拟机使用大型 页数

---

为我将主机cpu传递到VM work，这将提供VM pdpe1gb cpu标志

---

我使用Qemu+libvirt，在主机上启用1G hugepagesz。

可能会有帮助。在vm描述的xml中设置cpu属性，如下所示：

  <cpu mode='custom' match='exact' check='partial'>
      <model fallback='allow'>Broadwell</model>
      <feature policy='force' name='pdpe1gb'/>
  </cpu>

布罗德韦尔

您的

dmesg

中有什么？ESXi也应配置为1G页面分配和支持；当虚拟机监控程序没有真正的1G物理页面时，来宾不能要求1G页面。ESXi可能不支持1G页面。例如，对于RedHat主机，应在主机操作系统中分配1GB页面：[root@localhost~]#dmesg | grep-i