What will happen if huge pages are configured but sysctl parameter vm.hugetlb_shm_group remains set to default value?
Environment
- Red Hat Enterprise Linux 5 or later
Issue
- We have configured huge pages and enabled them within the application but the application still cannot allocate huge pages.
- What will happen if huge pages are configured but sysctl parameter
vm.hugetlb_shm_group
remains set to default value? - How do huge pages work?
- If vm.hugetlb_shm_group is set to the GID of a running process, will the change take effect without a process restart?
Resolution
-
The sysctl parameter
vm.hugetlb_shm_group
contains a group id that is allowed to create SysV shared memory segment using hugetlb page. Users who wish to use hugetlb memory via shared memory segment should be a member of a supplementary group and system admin needs to configure that gid intovm.hugetlb_shm_group
. Doing this grants the members of a group permission to create shared memory segments. -
Once this change is made, processes running with the GID specified in vm.hugetlb_shm_group will be allowed to create shared memory segments without needing to restart.
Note: Only the users who belong to the group listed in
vm.hugetlb_shm_group
will be able to useshmget()
andshmat()
calls to access the HugePages. It is possible for same or different applications to use any combination ofmmap()
&shm*()
calls, though the mount of filesystem will be required for usingmmap()
calls without MAP_HUGETLB. -
The default value of sysctl parameter
vm.hugetlb_shm_group
is 0 which means only applications running with root user privilege are allowed to create SysV shared using hugetlb page. Oracle database or java programs usually should not be started by the root user. Hence it is mandatory to set eithercap_ipc_lock
for the binary or dedicated group id invm.hugetlb_shm_group
to make successful allocation of SysV shared memory segment. -
If you need help with setting sysctl variable, please see How to set sysctl variables on Red Hat Enterprise Linux.
Points to consider:
-
In RHEL 8 and prior to RHEL 9.2, the
memlock
ulimt allowed users to allocate hugepages usingshmget()
without settingcap_ipc_lock
or adding a GID tovm.hugetlb_shm_group
. However, starting from RHEL 9.2, this is no longer possible due to the following commit2b81629f1d52 mm,hugetlb: remove mlock ulimit for SHM_HUGETLB
. Therefore, from RHEL 9.2 onwards, it is mandatory to set eithercap_ipc_lock
for the binary or dedicated group id invm.hugetlb_shm_group
to make successful allocation of SysV shared memory segment. -
Note:- If the
nosuid
mount option is set on the filesystem where the hugepage allocation program is located and thecap_ipc_lock
is for the binary , the hugepage allocation will fail with anshmget failed for huge pages: Operation not permitted(
EPERM)
error. In this case , adding a GID tovm.hugetlb_shm_group
is necessary.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments