On 10 Mar 2026, at 5:49, Sayali Patil wrote:
> The charge_reserved_hugetlb.sh script assumes hugetlb cgroup memory
> interface file names use the "<size>MB" format
> (e.g. hugetlb.1024MB.current).
> This assumption breaks on systems with larger huge pages such as 1GB,
> where the kernel exposes normalized units:
> hugetlb.1GB.current
> hugetlb.1GB.max
> hugetlb.1GB.rsvd.max
> ...
>
> As a result, the script attempts to access files like
> hugetlb.1024MB.current, which do not exist when the kernel reports the
> size in GB.
>
> Normalize the huge page size and construct the pathname using the
> appropriate unit (MB or GB), matching the hugetlb controller naming.
>
> Fixes: 209376ed2a84 ("selftests/vm: make charge_reserved_hugetlb.sh work with
> existing cgroup setting")
> Fixes: 29750f71a9b4 ("hugetlb_cgroup: add hugetlb_cgroup reservation tests")
> Signed-off-by: Sayali Patil <[email protected]>
> ---
> .../selftests/mm/charge_reserved_hugetlb.sh | 42 +++++++++++++------
> 1 file changed, 29 insertions(+), 13 deletions(-)
>
> diff --git a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
> b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
> index c9fe68b6fcf9..6bec53e16e05 100755
> --- a/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
> +++ b/tools/testing/selftests/mm/charge_reserved_hugetlb.sh
> @@ -89,6 +89,15 @@ function get_machine_hugepage_size() {
> }
>
> MB=$(get_machine_hugepage_size)
> +if (( MB >= 1024 )); then
> + # For 1GB hugepages
> + UNIT="GB"
> + MB_DISPLAY=$((MB / 1024))
> +else
> + # For 2MB hugepages
> + UNIT="MB"
> + MB_DISPLAY=$MB
> +fi
>
> function setup_cgroup() {
> local name="$1"
> @@ -98,11 +107,12 @@ function setup_cgroup() {
> mkdir $cgroup_path/$name
>
> echo writing cgroup limit: "$cgroup_limit"
> - echo "$cgroup_limit" >$cgroup_path/$name/hugetlb.${MB}MB.$fault_limit_file
> + echo "$cgroup_limit" > \
> + $cgroup_path/$name/hugetlb.${MB_DISPLAY}${UNIT}.$fault_limit_file
MB_DISPLAY and UNIT always show up together, maybe just use a single variable
instead. But feel free to ignore this. Anyway,
Reviewed-by: Zi Yan <[email protected]>
Best Regards,
Yan, Zi
