透明巨页支持¶
目标¶
处理大型内存工作集的性能关键型计算应用程序已经在 libhugetlbfs 和 hugetlbfs 之上运行。 透明巨页支持 (THP) 是一种使用巨页支持虚拟内存的替代方法,它支持页面大小的自动提升和降级,并且没有 hugetlbfs 的缺点。
目前,THP 仅适用于匿名内存映射和 tmpfs/shmem。 但将来它可以扩展到其他文件系统。
注意
在下面的示例中,我们假定基本页面大小为 4K,巨页大小为 2M,尽管实际数字可能因 CPU 架构而异。
应用程序运行速度更快的原因有两个。 第一个因素几乎完全无关紧要,而且没有什么意义,因为它也会带来在缺页中断中需要更大的清除页面复制页面的缺点,这可能是一个负面影响。 第一个因素包括为用户空间触及的每个 2M 虚拟区域获取单个缺页中断(因此将进入/退出内核的频率降低了 512 倍)。 这仅在内存映射生命周期内第一次访问内存时才重要。 第二个持久且更重要的因素将影响应用程序整个运行时对内存的所有后续访问。 第二个因素包括两个组成部分
TLB 未命中将运行得更快(尤其是在使用嵌套页表的虚拟化中,但几乎总是在没有虚拟化的裸机上也是如此)
单个 TLB 条目将映射更大的虚拟内存量,从而减少 TLB 未命中的数量。 对于使用嵌套页表的虚拟化,只有当 KVM 和 Linux 客户机都使用巨页时,TLB 才能映射更大的尺寸,但仅仅因为 TLB 未命中运行得更快,即使只有其中一个使用巨页,也会发生显着的加速。
现代内核支持“多大小 THP”(mTHP),它引入了以大于基本页面但小于传统 PMD 大小(如上所述)的块分配内存的能力,增量为 2 的幂次方的页面数。 mTHP 可以支持匿名内存(例如 16K、32K、64K 等)。 这些 THP 继续以 PTE 映射,但在许多情况下仍然可以提供与上述类似的优势:缺页中断显着减少(例如,减少 4 倍、8 倍、16 倍等),但延迟峰值不太突出,因为每个页面的大小不像 PMD 大小的变体那样巨大,并且在每个缺页中断中需要清除的内存更少。 某些架构还采用 TLB 压缩机制,以便在 PTE 集在虚拟和物理上连续且适当对齐时挤压更多条目。 在这种情况下,TLB 未命中将不太频繁地发生。
THP 可以系统范围内启用,也可以限制为某些任务,甚至限制在任务地址空间内的内存范围。 除非 THP 完全禁用,否则有一个 khugepaged
守护进程扫描内存并将基本页面序列折叠成 PMD 大小的巨页。
THP 的行为通过 sysfs 接口以及使用 madvise(2) 和 prctl(2) 系统调用来控制。
与 hugetlbfs 的预留方法相比,透明巨页支持通过允许所有未使用的内存用作缓存或其他可移动(甚至不可移动的实体)来最大限度地提高空闲内存的利用率。 它不需要预留以防止用户空间注意到巨页分配失败。 它允许在巨页上使用分页和所有其他高级 VM 功能。 它不需要应用程序进行修改即可利用它。
但是,应用程序可以进一步优化以利用此功能,就像之前已经优化过以避免为每个 malloc(4k) 产生大量的 mmap 系统调用一样。 优化用户空间远非强制性的,即使对于处理大量内存的巨页感知较差的应用程序,khugepaged 也可以处理长期存在的页面分配。
在某些情况下,当系统范围内启用巨页时,应用程序最终可能会分配更多的内存资源。 应用程序可能会 mmap 一个很大的区域,但只触及其中的 1 个字节,在这种情况下,可能会分配一个 2M 的页面而不是一个 4k 的页面,这样做没有好处。 这就是为什么可以禁用系统范围内的巨页,而只在 MADV_HUGEPAGE madvise 区域中使用它们的原因。
嵌入式系统应仅在 madvise 区域内启用巨页,以消除浪费任何宝贵字节内存的风险,并仅运行得更快。
从巨页中获得很多好处并且不会因使用巨页而有丢失内存风险的应用程序,应在其关键的 mmapped 区域上使用 madvise(MADV_HUGEPAGE)。
sysfs¶
全局 THP 控制¶
可以完全禁用用于匿名内存的透明巨页支持(主要用于调试目的),或者仅在 MADV_HUGEPAGE 区域内启用(以避免消耗更多内存资源的风险),或者在系统范围内启用。 可以通过以下方式针对每个支持的 THP 大小实现此目的
echo always >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
echo never >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
其中 <size> 是正在寻址的巨页大小,可用大小因系统而异。
例如
echo always >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
或者,可以指定给定的巨页大小将继承顶层“enabled”值
echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
例如
echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
可以使用以下命令之一设置顶层设置(用于“inherit”)
echo always >/sys/kernel/mm/transparent_hugepage/enabled
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
echo never >/sys/kernel/mm/transparent_hugepage/enabled
默认情况下,PMD 大小的巨页具有 enabled="inherit",所有其他巨页大小具有 enabled="never"。 如果启用多个巨页大小,内核将为给定的分配选择最合适的已启用大小。
还可以限制 VM 中的碎片整理工作,以生成匿名巨页,以防它们不能立即用于 madvise 区域,或者永远不要尝试对内存进行碎片整理,除非巨页立即可用,否则只需回退到常规页面。 显然,如果我们花费 CPU 时间来整理内存,我们希望通过以后使用巨页而不是常规页面来获得更多收益。 这并不能总是保证,但如果分配用于 MADV_HUGEPAGE 区域,则可能更有可能。
echo always >/sys/kernel/mm/transparent_hugepage/defrag
echo defer >/sys/kernel/mm/transparent_hugepage/defrag
echo defer+madvise >/sys/kernel/mm/transparent_hugepage/defrag
echo madvise >/sys/kernel/mm/transparent_hugepage/defrag
echo never >/sys/kernel/mm/transparent_hugepage/defrag
- always
表示请求 THP 的应用程序将在分配失败时停止,并直接回收页面和压缩内存,以立即分配 THP。 这对于从 THP 使用中受益匪浅并愿意延迟 VM 启动以利用它们的虚拟机来说是可取的。
- defer
表示应用程序将在后台唤醒 kswapd 以回收页面,并唤醒 kcompactd 以压缩内存,以便在不久的将来可以使用 THP。 然后由 khugepaged 负责稍后安装 THP 页面。
- defer+madvise
将像
always
一样进入直接回收和压缩,但仅适用于已使用 madvise(MADV_HUGEPAGE) 的区域; 所有其他区域将在后台唤醒 kswapd 以回收页面,并唤醒 kcompactd 以压缩内存,以便在不久的将来可以使用 THP。- madvise
将像
always
一样进入直接回收,但仅适用于已使用 madvise(MADV_HUGEPAGE) 的区域。 这是默认行为。- never
应该是不言自明的。
默认情况下,内核尝试在读取缺页中断时使用巨大的、PMD 可映射的零页面来匿名映射。 可以通过写入 0 来禁用巨大的零页面,或者通过写入 1 来重新启用它
echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page
echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page
某些用户空间(例如测试程序或优化的内存分配库)可能想知道 PMD 可映射透明巨页的大小(以字节为单位)
cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
所有在缺页中断和折叠时的 THP 都将被添加到 _deferred_list 中,因此如果它们被认为是“未充分利用”,将在内存压力下被拆分。 如果 THP 中填充零的页面的数量高于 max_ptes_none(参见下文),则 THP 未被充分利用。 可以通过写入 0 到 shrink_underused 来禁用此行为,并通过写入 1 到它来启用它
echo 0 > /sys/kernel/mm/transparent_hugepage/shrink_underused
echo 1 > /sys/kernel/mm/transparent_hugepage/shrink_underused
当启用 PMD 大小的 THP 时(per-size anon 控制或顶层控制设置为“always”或“madvise”),khugepaged 将自动启动,当禁用 PMD 大小的 THP 时(per-size anon 控制和顶层控制都为“never”),它将自动关闭
Khugepaged 控制¶
注意
khugepaged 目前仅搜索折叠到 PMD 大小的 THP 的机会,并且没有尝试折叠到其他 THP 大小。
khugepaged 通常以低频率运行,因此虽然可能不想在缺页中断期间同步调用碎片整理算法,但至少在 khugepaged 中调用碎片整理应该是值得的。 但是,也可以通过写入 0 来禁用 khugepaged 中的碎片整理,或者通过写入 1 来启用 khugepaged 中的碎片整理
echo 0 >/sys/kernel/mm/transparent_hugepage/khugepaged/defrag
echo 1 >/sys/kernel/mm/transparent_hugepage/khugepaged/defrag
您还可以控制 khugepaged 每次扫描多少页
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_to_scan
以及 khugepaged 在每次传递之间等待多少毫秒(您可以将其设置为 0 以 100% 利用一个核心运行 khugepaged)
/sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs
以及如果在巨页分配失败时 khugepaged 等待多少毫秒来限制下一次分配尝试
/sys/kernel/mm/transparent_hugepage/khugepaged/alloc_sleep_millisecs
可以在折叠的页面数量中看到 khugepaged 的进度(请注意,此计数器可能不是折叠的页面数量的精确计数,因为“折叠”可能意味着多种含义:(1)PTE 映射被 PMD 映射替换,或(2)所有 4K 物理页面被一个 2M 巨页替换。 每个可能独立发生,或一起发生,具体取决于内存类型和发生的故障。 因此,此值应大致解释为进度的标志,并且应咨询 /proc/vmstat 中的计数器以进行更准确的核算)
/sys/kernel/mm/transparent_hugepage/khugepaged/pages_collapsed
对于每次传递
/sys/kernel/mm/transparent_hugepage/khugepaged/full_scans
max_ptes_none
指定在将一组小页面折叠成一个大页面时可以分配多少个额外的小页面(尚未映射)
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none
较高的值会导致程序使用更多的内存。 较低的值会导致更少的 thp 性能。 max_ptes_none 的值可以浪费非常少的 cpu 时间,您可以忽略它。
max_ptes_swap
指定在将一组页面折叠成透明巨页时可以从交换空间中调入多少个页面
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap
较高的值可能导致过多的交换 IO 并浪费内存。 较低的值可以阻止 THP 被折叠,导致更少的页面被折叠成 THP,并降低内存访问性能。
max_ptes_shared
指定可以在多个进程之间共享多少个页面。 如果 THP 的任何页面被共享,khugepaged 可能会将 THP 的页面视为共享。 超过此数量将阻止折叠
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared
较高的值可能会增加某些工作负载的内存占用。
启动参数¶
您可以通过将参数 transparent_hugepage=always
或 transparent_hugepage=madvise
或 transparent_hugepage=never
传递到内核命令行来更改顶层“enabled”控制的 sysfs 启动时间默认值。
或者,可以通过传递 thp_anon=<size>[KMG],<size>[KMG]:<state>;<size>[KMG]-<size>[KMG]:<state>
来控制每个支持的匿名 THP 大小,其中 <size>
是 THP 大小(必须是 PAGE_SIZE 的 2 的幂次且受支持的匿名 THP),并且 <state>
是 always
、madvise
、never
或 inherit
之一。
例如,以下设置将 16K、32K、64K THP 设置为 always
,将 128K、512K 设置为 inherit
,将 256K 设置为 madvise
,并将 1M、2M 设置为 never
thp_anon=16K-64K:always;128K,512K:inherit;256K:madvise;1M-2M:never
可以多次指定 thp_anon=
以根据需要配置所有 THP 大小。 如果至少指定一次 thp_anon=
,则命令行上未显式配置的任何匿名 THP 大小将隐式设置为 never
。
transparent_hugepage
设置仅影响全局切换。 如果未指定 thp_anon
,则 PMD_ORDER THP 将默认为 inherit
。 但是,如果用户提供了有效的 thp_anon
设置,则 PMD_ORDER THP 策略将被覆盖。 如果 PMD_ORDER 的策略未在有效的 thp_anon
中定义,则其策略将默认为 never
。
与 transparent_hugepage
类似,您可以使用内核参数 transparent_hugepage_shmem=<policy>
来控制内部 shmem 挂载的巨页分配策略,其中 <policy>
是 shmem 的七个有效策略之一(always
、within_size
、advise
、never
、deny
和 force
)。
与 transparent_hugepage_shmem
类似,您可以使用内核参数 transparent_hugepage_tmpfs=<policy>
来控制 tmpfs 挂载的默认巨页分配策略,其中 <policy>
是 tmpfs 的四个有效策略之一(always
、within_size
、advise
、never
)。 tmpfs 挂载的默认策略是 never
。
与 thp_anon
控制每个支持的匿名 THP 大小的方式相同,thp_shmem
控制每个支持的 shmem THP 大小。 thp_shmem
的格式与 thp_anon
相同,但也支持策略 within_size
。
可以多次指定 thp_shmem=
以根据需要配置所有 THP 大小。 如果至少指定一次 thp_shmem=
,则命令行上未显式配置的任何 shmem THP 大小将隐式设置为 never
。
transparent_hugepage_shmem
设置仅影响全局切换。 如果未指定 thp_shmem
,则 PMD_ORDER 巨页将默认为 inherit
。 但是,如果用户提供了有效的 thp_shmem
设置,则 PMD_ORDER 巨页策略将被覆盖。 如果 PMD_ORDER 的策略未在有效的 thp_shmem
中定义,则其策略将默认为 never
。
tmpfs/shmem 中的巨页¶
传统上,tmpfs 仅支持单个巨页大小 ("PMD")。 今天,它也像匿名内存一样支持更小的大小,通常称为“多大小 THP”(mTHP)。 任何大小的巨页通常在内核中表示为“大 folio”。
虽然可以对用于内部 shmem 挂载的巨页大小进行精细控制(请参见下文),但普通 tmpfs 挂载将利用所有可用的巨页大小,而无需对确切大小进行任何控制,其行为更类似于其他文件系统。
tmpfs 挂载¶
可以使用挂载选项调整 tmpfs 挂载的 THP 分配策略: huge=
。 它可以具有以下值
- always
每次需要新页面时都尝试分配巨页;
- never
不要分配巨页;
- within_size
仅当它完全在 i_size 内时才分配巨页。 还要尊重 madvise() 提示;
- advise
仅在通过 madvise() 请求时才分配巨页;
请记住,内核可以使用所有可用大小的巨页,并且无法像内部 tmpfs 挂载那样进行精细控制。
过去的默认策略是 never
,但现在可以使用内核参数 transparent_hugepage_tmpfs=<policy>
进行调整。
mount -o remount,huge= /mountpoint
在挂载后工作正常:重新挂载 huge=never
完全不会尝试分解巨页,只会阻止分配更多巨页。
除了上面列出的策略之外,当设置为以下值时,sysfs knob /sys/kernel/mm/transparent_hugepage/shmem_enabled 将影响 tmpfs 挂载的分配策略
- deny
用于紧急情况,以强制从所有挂载中关闭 huge 选项;
- force
强制为所有挂载启用 huge 选项 - 对于测试非常有用;
shmem / 内部 tmpfs¶
内部 tmpfs 挂载用于 SysV SHM、memfds、共享匿名 mmaps(/dev/zero 或 MAP_ANONYMOUS)、GPU 驱动程序的 DRM 对象、Ashmem。
要控制此内部 tmpfs 挂载的 THP 分配策略,可以使用 sysfs knob /sys/kernel/mm/transparent_hugepage/shmem_enabled 以及 '/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/shmem_enabled' 中每个 THP 大小的 knobs。
全局 knob 具有与 tmpfs 挂载的 huge=
挂载选项相同的语义,不同之处在于可以单独控制不同的巨页大小,并且只有当每个大小的 knob 设置为“inherit”时才会使用全局 knob 的设置。
对于各个大小,将删除选项“force”和“deny”,这些选项是旧时代的测试产物。
- always
每次需要新页面时都尝试分配 <size> 巨页;
- inherit
继承顶层“shmem_enabled”值。 默认情况下,PMD 大小的巨页具有 enabled="inherit",所有其他巨页大小具有 enabled="never";
- never
不要分配 <size> 巨页;
- within_size
仅当它完全在 i_size 内时才分配 <size> 巨页。 还要尊重 madvise() 提示;
- advise
仅在通过 madvise() 请求时才分配 <size> 巨页;
需要重新启动应用程序¶
transparent_hugepage/enabled 和 transparent_hugepage/hugepages-<size>kB/enabled 值以及 tmpfs 挂载选项仅影响未来的行为。 因此,要使它们生效,您需要重新启动任何可能一直在使用巨页的应用程序。 这也适用于 khugepaged 中注册的区域。
监控使用情况¶
系统当前使用的 PMD 大小的匿名透明巨页的数量可以通过读取 /proc/meminfo
中的 AnonHugePages 字段获得。 要确定哪些应用程序正在使用 PMD 大小的匿名透明巨页,需要读取 /proc/PID/smaps
并计算每个映射的 AnonHugePages 字段。(请注意,由于历史原因,AnonHugePages 仅适用于传统的 PMD 大小的 THP,应该称为 AnonHugePmdMapped)。
映射到用户空间的文件透明巨页的数量可以通过读取 /proc/meminfo
中的 ShmemPmdMapped 和 ShmemHugePages 字段获得。 要确定哪些应用程序正在映射文件透明巨页,需要读取 /proc/PID/smaps
并计算每个映射的 FilePmdMapped 字段。
请注意,读取 smaps 文件成本很高,并且频繁读取会产生开销。
/proc/vmstat
中有许多计数器可用于监控系统成功提供巨页以供使用的情况。
- thp_fault_alloc
每次成功分配巨页并将其记入处理缺页中断时,该值都会递增。
- thp_collapse_alloc
当 khugepaged 找到要折叠成一个巨页的页面范围并成功分配新的巨页来存储数据时,该值会递增。
- thp_fault_fallback
如果缺页中断无法分配或记入巨页,而是回退到使用小页面,则该值会递增。
- thp_fault_fallback_charge
如果缺页中断无法记入巨页,而是回退到使用小页面,即使分配成功,该值也会递增。
- thp_collapse_alloc_failed
如果 khugepaged 找到应该折叠成一个巨页的页面范围但分配失败,则该值会递增。
- thp_file_alloc
每次成功分配 shmem 巨页时,该值都会递增(请注意,尽管以“file”命名,但计数器仅测量 shmem)。
- thp_file_fallback
如果尝试分配 shmem 巨页但失败,而是回退到使用小页面,则该值会递增。(请注意,尽管以“file”命名,但计数器仅测量 shmem)。
- thp_file_fallback_charge
如果无法记入 shmem 巨页,而是回退到使用小页面,即使分配成功,该值也会递增。(请注意,尽管以“file”命名,但计数器仅测量 shmem)。
- thp_file_mapped
每次将文件或 shmem 巨页映射到用户地址空间时,该值都会递增。
- thp_split_page
每次将巨页拆分为基本页面时,该值都会递增。 这可能会因各种原因而发生,但一个常见原因是巨页已过时并且正在被回收。 此操作意味着拆分所有 PMD 页面映射的页面。
- thp_split_page_failed
如果内核无法拆分巨页,则该值会递增。 如果页面被某人锁定,则可能会发生这种情况。
- thp_deferred_split_page
当将巨页放入拆分队列时,该值会递增。 当巨页被部分取消映射并且拆分它可以释放一些内存时,会发生这种情况。 拆分队列中的页面将在内存压力下拆分。
- thp_underused_split_page
当分割队列上的大页因利用率不足而被分割时,该计数器会递增。如果 THP 中的零页数量超过某个阈值(/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_none),则认为 THP 利用率不足。
- thp_split_pmd
每次 PMD 分割成 PTE 表时,该计数器都会递增。例如,当应用程序对大页的一部分调用 mprotect() 或 munmap() 时,可能会发生这种情况。它不会分割大页,只会分割页表项。
- thp_zero_page_alloc
每次成功分配用于 thp 的巨大零页时,该计数器都会递增。请注意,它不会统计巨大零页的每次映射,仅统计其分配。
- thp_zero_page_alloc_failed
如果内核未能分配巨大的零页,并且回退到使用小页面,则该计数器会递增。
- thp_swpout
每次将大页作为一个整体换出而没有分割时,该计数器都会递增。
- thp_swpout_fallback
如果大页在换出之前必须分割,则该计数器会递增。通常是因为未能为该大页分配一些连续的交换空间。
在 /sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/stats 中,还有每个大页大小的单独计数器,可用于监视系统在提供大页以供使用方面的效率。每个计数器都有其对应的文件。
- anon_fault_alloc
每次成功分配巨页并将其记入处理缺页中断时,该值都会递增。
- anon_fault_fallback
如果页面错误未能分配或收取大页的费用,而是回退到使用较低阶的大页或小页,则该计数器会递增。
- anon_fault_fallback_charge
即使分配成功,如果页面错误未能收取大页的费用,而是回退到使用较低阶的大页或小页,则该计数器会递增。
- zswpout
每次将大页作为一个整体换出到 zswap 而没有分割时,该计数器都会递增。
- swpin
每次将大页从非 zswap 交换设备作为一个整体换入时,该计数器都会递增。
- swpin_fallback
如果 swapin 未能分配或收取大页的费用,而是回退到使用较低阶的大页或小页,则该计数器会递增。
- swpin_fallback_charge
即使分配成功,如果 swapin 未能收取大页的费用,而是回退到使用较低阶的大页或小页,则该计数器会递增。
- swpout
每次将大页作为一个整体换出到非 zswap 交换设备而没有分割时,该计数器都会递增。
- swpout_fallback
如果大页在换出之前必须分割,则该计数器会递增。通常是因为未能为该大页分配一些连续的交换空间。
- shmem_alloc
每次成功分配 shmem 大页时,该计数器都会递增。
- shmem_fallback
如果尝试分配 shmem 大页但失败,而是回退到使用小页,则该计数器会递增。
- shmem_fallback_charge
如果 shmem 大页无法收取费用,而是回退到使用小页(即使分配成功),则该计数器会递增。
- split
每次成功将大页分割成较小阶数时,该计数器都会递增。 发生这种情况的原因有很多,但一个常见的原因是大页已旧,正在被回收。
- split_failed
如果内核无法拆分巨页,则该值会递增。 如果页面被某人锁定,则可能会发生这种情况。
- split_deferred
当大页被放入分割队列时,该计数器会递增。 当大页被部分取消映射并且分割它可以释放一些内存时,会发生这种情况。 分割队列上的页面将在内存压力下分割(如果可以分割)。
- nr_anon
系统中存在的匿名 THP 的数量。 这些 THP 可能当前已完全映射,或者具有部分取消映射/未使用的子页面。
- nr_anon_partially_mapped
可能部分映射、可能浪费内存并且已排队等待延迟内存回收的匿名 THP 的数量。 请注意,在某些极端情况下(例如,迁移失败),我们可能会将匿名 THP 检测为“部分映射”并在此处计数,即使它实际上不再是部分映射。
随着系统老化,分配大页可能会很昂贵,因为系统使用内存压缩在内存中复制数据以释放一个大页以供使用。 /proc/vmstat
中有一些计数器可以帮助监视此开销。
- compact_stall
每次进程停顿以运行内存压缩,以便释放一个大页以供使用时,该计数器都会递增。
- compact_success
如果系统压缩了内存并释放了一个大页以供使用,则该计数器会递增。
- compact_fail
如果系统尝试压缩内存但失败,则该计数器会递增。
可以使用函数跟踪器记录在 __alloc_pages() 中花费的时间,并使用 mm_page_alloc 跟踪点识别哪些分配用于大页,从而确定停顿的持续时间。
优化应用程序¶
为了保证内核会立即在任何内存区域中映射 THP,mmap 区域必须与 hugepage 自然对齐。 posix_memalign() 可以提供这种保证。
Hugetlbfs¶
您可以在启用透明大页支持的内核上像往常一样使用 hugetlbfs。 hugetlbfs 中没有其他区别,只是整体碎片会更少。 属于 hugetlbfs 的所有常用功能都将保留且不受影响。 libhugetlbfs 也能像往常一样正常工作。