一、HugePages大页内存

1.1 物理内存与虚拟内存

物理内存 也称为实际内存或硬件内存，是计算机中实际安装的内存条的容量。

虚拟内存 是一种利用硬盘空间来扩展物理内存的技术，它允许计算机将暂时不需要的数据和程序从物理内存中转移到硬盘上，以释放出物理内存空间。当这些数据和程序再次需要时，它们可以被重新加载到物理内存中。

1.2 MMU与内存页

MMU (Memory Mangement Unit)，核心思想是利用虚拟地址替代物理地址，即CPU寻址时使用虚址，由MMU负责将虚址映射为物理地址。

内存页 (Memory paging)，是基于MMU的一种内存管理机制，它将虚拟地址和物理地址按固定大小(通常是4K)分割成页(page)和页帧(page frame)，这种机制，从数据结构上保证了访问内存的高效，并使操作系统能支持非连续性的内存分配。

虚拟内存和物理内存的映射关系保存在页表(page table)中，为了进一步优化性能，现代CPU架构引入了 TLB (Translation Lookaside Buffer)，用来缓存一部分经常访问的页表内容。

1.3 HugePages大页内存

TLB有大小限制，当超出TLB上限时，就会发生TLB miss，如果频繁的出现TLB miss，程序的性能会下降的很快。为了让TLB可以存储更多的页地址映射关系，通常的做法是调大内存分页大小， 一般把大于4K的页，统称为大页(HugePages) 。

假设一个程序需要64G内存，如果内存页大小是4K，就会有64G/4k=4194304(410241024)个页表，超过TLB上限，出现TLB miss；而如果把内存页大小设置为2M，则只有64G/2M=8192(8*1024)个页表。

二、linux中使用HugePages

查看HugePages

# cat /proc/meminfo | grep Huge
AnonHugePages:     96256 kB
ShmemHugePages:        0 kB
FileHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB # 2Mi的大页内存
Hugetlb:               0 kB

调整HugePages：

# echo 128 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

再次查看HugePages信息：

# cat /proc/meminfo | grep Huge
AnonHugePages:    100352 kB
ShmemHugePages:        0 kB
FileHugePages:         0 kB
HugePages_Total:     128
HugePages_Free:      128
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:        17039360 kB

三、kubernetes中使用HugePages

kubernetes中使用Hugepages是在pod中配置的，官网说明可参考说明：Manage HugePages，本章节只做搬运工。

3.1 前提

为了使节点能够上报HugePages容量，Kubernetes节点必须预先分配HugePages，每个节点支持预先分配多种规格的HugePages。

3.2 API

用户可以通过在容器级别的资源需求中使用资源名称 hugepages- 来使用HugePages，其中的 size 是特定节点上支持的以整数值表示的最小二进制单位。例如，如果一个节点支持 2048KiB 和 1048576KiB 页面大小，它将公开可调度的资源 hugepages-2Mi 和 hugepages-1Gi。与 CPU 或普通内存不同，HugePages不支持超分（overcommit）。注意，在请求HugePages资源时，还必须请求普通内存或 CPU 资源。

同一 Pod 的 spec 中可能会消耗不同尺寸的HugePages。在这种情况下，它必须对所有挂载卷使用 medium: HugePages- 标识：

apiVersion: v1
kind: Pod
metadata:name: huge-pages-example
spec:containers:- name: exampleimage: fedora:latestcommand:- sleep- infvolumeMounts:- mountPath: /hugepages-2Miname: hugepage-2mi- mountPath: /hugepages-1Giname: hugepage-1giresources:limits:hugepages-2Mi: 100Mihugepages-1Gi: 2Gimemory: 100Mirequests:memory: 100Mivolumes:- name: hugepage-2miemptyDir:medium: HugePages-2Mi- name: hugepage-1giemptyDir:medium: HugePages-1Gi

Pod 只有在请求同一大小的巨页时才使用 medium：HugePages：

apiVersion: v1
kind: Pod
metadata:name: huge-pages-example
spec:containers:- name: exampleimage: fedora:latestcommand:- sleep- infvolumeMounts:- mountPath: /hugepagesname: hugepageresources:limits:hugepages-2Mi: 100Mimemory: 100Mirequests:memory: 100Mivolumes:- name: hugepageemptyDir:medium: HugePages

注意事项：

HugePages的request必须等于limit
HugePages是在容器级别隔离的，因此每个容器都可以有自己的Hugepages规格配置
HugePages可用于 EmptyDir 卷，不过 EmptyDir 卷所使用的大小不能够超出 Pod request的HugePages大小
通过带有 SHM_HUGETLB 的 shmget() 使用HugePages的应用，必须运行在一个与 proc/sys/vm/hugetlb_shm_group 匹配的补充组下
可以通过 ResourceQuota 来限制HugePages的用量，类似于 cpu 或 memory 等其他计算资源，HugePages使用hugepages- 标识

四、kubevirt中使用HugePages

以下内容基于kubevirt@0.26.0

kubevirt中给给虚拟机使用HugePages是在vmi对象中配置的：

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstance
metadata:name: vmi-testnamespace: public
spec:domain:cpu:cores: 67 # 注意这个参数，这里是随意设置，但是后面会用到model: host-passthroughsockets: 1threads: 1devices:inputs:- bus: usbname: input0type: tabletinterfaces:- masquerade: {}name: defaultfeatures:acpi:enabled: trueioThreadsPolicy: automachine:type: q35memory:hugepages:pageSize: 2Mi # 使用2Mi的HugePagesresources:limits:cpu: "4"memory: 4Gi # 和request memory相等requests:cpu: "2"memory: 4Gi # 和limit memory相等networks:- name: defaultpod: {}

创建完该vmi后，生成的pod如下（只保留了相关字段）：

apiVersion: v1
kind: Pod
metadata:name: virt-launcher-test-vmi-hv8svnamespace: public
spec:containers:- name: computeresources:limits:cpu: "4"hugepages-2Mi: 4Gi # 2Mi大页内存大小被设置成了vmi request/limit memory大小memory: "723591169" # ？？？requests:cpu: "2"hugepages-2Mi: 4Gi # 2Mi大页内存大小被设置成了vmi request/limit memory大小memory: "723591169" # ？？？volumeMounts:- mountPath: /dev/hugepagesname: hugepagesvolumes:- emptyDir:medium: HugePagesname: hugepages

上面pod yaml的request/limit下cpu、hugepages-2Mi数值都可以理解，但request/limit下的memory被设置为了723591169，这是什么？要回答这个问题，得看看kubevirt源码：

// pkg/virt-controller/services/template.go
func (t *templateService) RenderLaunchManifest(vmi *v1.VirtualMachineInstance) (*k8sv1.Pod, error) {/*...*/// Get memory overheadmemoryOverhead := getMemoryOverhead(vmi.Spec.Domain)/*...*/// Consider hugepages resource for pod schedulingif vmi.Spec.Domain.Memory != nil && vmi.Spec.Domain.Memory.Hugepages != nil {hugepageType := k8sv1.ResourceName(k8sv1.ResourceHugePagesPrefix + vmi.Spec.Domain.Memory.Hugepages.PageSize)resources.Requests[hugepageType] = resources.Requests[k8sv1.ResourceMemory]resources.Limits[hugepageType] = resources.Requests[k8sv1.ResourceMemory]// Configure hugepages mount on a podvolumeMounts = append(volumeMounts, k8sv1.VolumeMount{Name:      "hugepages",MountPath: filepath.Join("/dev/hugepages"),})volumes = append(volumes, k8sv1.Volume{Name: "hugepages",VolumeSource: k8sv1.VolumeSource{EmptyDir: &k8sv1.EmptyDirVolumeSource{Medium: k8sv1.StorageMediumHugePages,},},})// 如果开启了HugePages，会把limit/request memory设置为memoryOverheadresources.Requests[k8sv1.ResourceMemory] = *memoryOverheadif _, ok := resources.Limits[k8sv1.ResourceMemory]; ok {resources.Limits[k8sv1.ResourceMemory] = *memoryOverhead}} else {// Add overhead memorymemoryRequest := resources.Requests[k8sv1.ResourceMemory]if !vmi.Spec.Domain.Resources.OvercommitGuestOverhead {memoryRequest.Add(*memoryOverhead)}resources.Requests[k8sv1.ResourceMemory] = memoryRequestif memoryLimit, ok := resources.Limits[k8sv1.ResourceMemory]; ok {memoryLimit.Add(*memoryOverhead)resources.Limits[k8sv1.ResourceMemory] = memoryLimit}}/*...*/
}

从上面代码可以看到，如果开启了HugePages，kubevirt会把pod的limit/request memory设置为memoryOverhead，memoryOverhead函数来自如下函数：

// getMemoryOverhead computes the estimation of total
// memory needed for the domain to operate properly.
// This includes the memory needed for the guest and memory
// for Qemu and OS overhead.
//
// The return value is overhead memory quantity
//
// Note: This is the best estimation we were able to come up with
//       and is still not 100% accurate
func getMemoryOverhead(domain v1.DomainSpec) *resource.Quantity {vmiMemoryReq := domain.Resources.Requests.Memory()overhead := resource.NewScaledQuantity(0, resource.Kilo)// Add the memory needed for pagetables (one bit for every 512b of RAM size)pagetableMemory := resource.NewScaledQuantity(vmiMemoryReq.ScaledValue(resource.Kilo), resource.Kilo)pagetableMemory.Set(pagetableMemory.Value() / 512)overhead.Add(*pagetableMemory)// Add fixed overhead for shared libraries and such// TODO account for the overhead of kubevirt components running in the podoverhead.Add(resource.MustParse("128M"))// Add CPU table overhead (8 MiB per vCPU and 8 MiB per IO thread)// overhead per vcpu in MiBcoresMemory := resource.MustParse("8Mi")if domain.CPU != nil {value := coresMemory.Value() * int64(domain.CPU.Cores)coresMemory = *resource.NewQuantity(value, coresMemory.Format)}overhead.Add(coresMemory)// static overhead for IOThreadoverhead.Add(resource.MustParse("8Mi"))// Add video RAM overheadif domain.Devices.AutoattachGraphicsDevice == nil || *domain.Devices.AutoattachGraphicsDevice == true {overhead.Add(resource.MustParse("16Mi"))}return overhead
}

从getMemoryOverhead函数中可以看出，overhead其实是给domain预留一定的普通内存。但是计算overhead时，如果vmi.spec.domain.cpu.cores配置了数值，overhead会加上8Mi * cores值。例如面vmi yaml中，request.memoty配置了4Gi，cpu.cores配置了67，根据getMemoryOverhead函数计算，overhead = 4Gi/512 + 128M + 8Mi*67 + 8Mi，统一单位后，就是723591169（大约0.7G），也就是pod yaml中看到的limit/request memory的值。

overhead的计算过程，说明创建一个vmi时，即使vmi中只声明了HugePages大页内存，kubevirt也会给pod额外使用一些普通内存，这一点在做精细化的资源调度的时候一定要注意，否则可能会因节点上的普通内存预留太少导致无法调度。

微信公众号卡巴斯同步发布，欢迎大家关注。

kubevirt（七）HugePages大页内存相关推荐

大页内存(HugePages)
原文转载自:http://blog.csdn.net/yutianzuijin/article/details/41912871 今天给大家介绍一种比较新奇的程序性能优化方法-大页内存(HugePag ...
大页内存的使用：HugePages（大内存页）的原理与使用
<DPDK | 如何在用户空间使用大页内存hugepage> <DPDK内存篇(三): 标准大页.NUMA.DMA.IOMMU.IOVA.内存池> <大页内存的使用:大页 ...
大页内存(HugePages)在通用程序优化中的应用
在介绍之前需要强调一点,大页内存也有适用范围,程序耗费内存很小或者程序的访存局部性很好,大页内存很难获得性能提升.所以,如果你面临的程序优化问题有上述两个特点,请不要考虑大页内存.后面会详细解释为啥具 ...
DPDK 大页内存实现（二十二）
上一篇文件介绍了linux内存管理以及大页内存的原理,有了原理的支撑,接下里分析dpdk大页内存源码就轻松了,才不会云里雾里不知道在说啥.所谓的dpdk大页内存的实现,说白了就是dpdk自己实现了一套 ...
DPDK 大页内存原理（二十一）
在分析dpdk大页内存的源码之前,有必要对linux内存管理的原理以及大页内存的原理有个了解,缺少这些底层基础知识,分析dpdk大页内存的源码将举步维艰.这篇文章详细介绍下linux内存管理以及大页内 ...
linux透明大页内存,rhel7.2 禁用透明的大页内存--transparent_hugepage(THP)
rhel7.2 禁用透明的大页内存--transparent_hugepage(TPH) [root@rac1 tmp]# cat /etc/redhat-release Red Hat Enterp ...
Linux 调优篇：虚拟化调优（hugepage 大页内存）* 叁
一. 大页(HugePages)概念 Hugepage的引入二. hugepages相关概念三.Regular Pages 与 HugePages a.Regular Pages ...
Linux之hugepage大页内存理论
目录 1.Hugepage的引入二.hugepages相关概念三.Regular Pages 与 HugePages a.Regular Pages b.Huge Pages 四. hugepag ...
linux大页内存 grub,Centos7.2使用1G大页面内存
1.创建大页内存挂接点 mkdir /mnt/huge_1GB mount -t hugetlbfs nodev /mnt/huge_1GB 2.在/etc/fstab文件中加入如下命令,使其重启后有 ...

kubevirt（七）HugePages大页内存