在应用程序执行过程中,许多动态库默认使用4KB小页,进程iTLB miss高,导致CPU执行效率低下。开源的代码段大页方案需要浪费额外的内存,同时影响进程启动速度,而OpenEuler提供的glibc加载动态库方案默认映射大页则可以减少内存开销,同时加快进程启动速度,最终能达到降低iTLB cache miss以提升性能的结果。该方法需要预先分配标准大页内存池,请先参考使能OS开启标准大页内存,确保有足够的标准大页内存空间。
openeuler源地址:https://repo.openeuler.org/,选择下面表格中符合要求的OpenEuler版本,例如:openEuler-22.03-LTS-SP4/docker_img/aarch64/openEuler-docker.aarch64.tar.xz)。
操作系统名称 |
软件版本要求 |
---|---|
OpenEuler |
操作系统版本:openEuler-22.03-LTS-SP1、openEuler-22.03-LTS-SP3、openEuler-22.03-LTS-SP4 上述OS版本对应软件版本要求均为,glibc版本和glibc-devel版本大于等于2.34-h157 。 |
EulerOS |
操作系统版本:eulerosv2r10、eulerosv2r11、eulerosv2r12、eulerosv2r13 eulerosv2r10对应glibc和glibc-devel的版本号为大于等于2.28-63.h52。 eulerosv2r11对应glibc和glibc-devel的版本号为大于等于2.34-70.h8。 eulerosv2r12对应glibc和glibc-devel的版本号为大于等于2.34-105.h1。 eulerosv2r13对应glibc和glibc-devel的版本号为大于等于2.34-143.h3。 |
建议采用rpm -qa glibc或者rpm -qa glibc-devel命令查询当前glibc版本,使用ldd --version只能看到glibc上游社区的版本,无法看到OpenEuler发行的h版本号。
rpm -qa glibc rpm -qa glibc-devel
yum install glibc-devel
yum upgrade glibc glibc-devel
使用LD_HUGEPAGE_LIB环境变量,会让可执行程序依赖的所有动态库都尝试映射大页。变量值为动态库的大页模式(当前仅支持0或1,其他值未定义):
该环境变量不会被复制到子进程,建议在运行程序入口配置,在外部shell脚本(非程序入口)设置不会生效,例如脚本训练入口:
export LD_HUGEPAGE_LIB=1 torchrun --nnodes=1 --nproc_per_node=8 --master-port 61888 scripts/train.py \ configs/opensora-v1-1/train/stage1.py
使能动态库大页,并非动态库的所有PT_LOAD段的映射都会使用大页,只有PT_LOAD段映射的区间覆盖了至少一个完整的2MB大页,才会尝试映射2MB大页。
可以通过readelf -l xxx.so来判断当前动态库LOAD段是否超过2M,下面以libtorch_npu.so为例:
上面图中,LOAD段对应VirtAddr和MemSiz分别为0x0000000000000000和0x0000000001bc47e4,段大小即MemSize为十六进制的0x0000000001bc47e4,转换为十进制之后为29116388字节,进一步计算为27M,超过了2M,因此libtorch_npu.so使用动态库大页可生效。
hugepageedit工具为glibc-devel包提供的二进制程序,若无此命令请参考上面使用方法中安装glibc-devel包命令。
hugepageedit <file>
hugepageedit -x <file>
hugepageedit -i <index> <file>
hugepageedit -d <file>
hugepageedit libtorch_npu.so export HUGEPAGE_PROBE=1