You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**`hugepageLimits`** (array of objects, OPTIONAL) represents the `hugetlb` controller which allows to limit the
487
-
HugeTLB usage per control group and enforces the controller limit during page fault.
486
+
**`hugepageLimits`** (array of objects, OPTIONAL) represents the `hugetlb` controller which allows to limit the HugeTLB reservations (if supported) or usage (page fault).
487
+
By default if supported by the kernel, `hugepageLimits` defines the hugepage sizes and limits for HugeTLB controller
488
+
reservation accounting, which allows to limit the HugeTLB reservations per control group and enforces the controller
489
+
limit at reservation time and at the fault of HugeTLB memory for which no reservation exists.
490
+
Otherwise if not supported by the kernel, this should fallback to the page fault accounting, which allows users to limit
491
+
the HugeTLB usage (page fault) per control group and enforces the limit during page fault.
492
+
493
+
Note that reservation limits are superior to page fault limits, since reservation limits are enforced at reservation
494
+
time (on mmap or shget), and never causes the application to get SIGBUS signal if the memory was reserved before hand.
495
+
This allows for easier fallback to alternatives such as non-HugeTLB memory for example. In the case of page fault
496
+
accounting, it's very hard to avoid processes getting SIGBUS since the sysadmin needs precisely know the HugeTLB usage
497
+
of all the tasks in the system and make sure there is enough pages to satisfy all requests. Avoiding tasks getting
498
+
SIGBUS on overcommited systems is practically impossible with page fault accounting.
499
+
488
500
For more information, see the kernel cgroups documentation about [HugeTLB][cgroup-v1-hugetlb].
0 commit comments