Skip to content

cgroup: write hugetlb reservation limits when supported - #2290

Open
Rajkaran-122 wants to merge 1 commit into
containers:mainfrom
Rajkaran-122:issue-2284-hugetlb-reservation-limits
Open

Rajkaran-122 wants to merge 1 commit into
containers:mainfrom
Rajkaran-122:issue-2284-hugetlb-reservation-limits

Conversation

@Rajkaran-122

Copy link
Copy Markdown
Contributor

For cgroup v2, write HugeTLB limits to both hugetlb..max and hugetlb..rsvd.max when the kernel supports reservation accounting. The reservation file may not exist on all kernels, so we silently ignore ENOENT errors and fall back to usage accounting.

Fixes #2284

@kolyshkin

Copy link
Copy Markdown
Collaborator

@Rajkaran-122 This might fix the failure in runc run (hugetlb limits), can you try removing it from the exception list in tests/runc-integration-skip.txt?

@Rajkaran-122

Rajkaran-122 commented Oct 1, 2026 •

Copy link
Copy Markdown
Contributor Author

@kolyshkin sir I removed runc run (hugetlb limits) from tests/runc-integration-skip.txt and reran the test locally.

It fails with load config.json: Required field 'pageSize' not present. The runc integration test generates pagesize, while the OCI config expects pageSize, so the test fails during config parsing before reaching the HugeTLB cgroup logic.

I restored the skip entry afterward. The PR-specific HugeTLB reservation-limit regression test passes.

@kolyshkin

Copy link
Copy Markdown
Collaborator

@kolyshkin sir I removed runc run (hugetlb limits) from tests/runc-integration-skip.txt and reran the test locally.

It fails with load config.json: Required field 'pageSize' not present. The runc integration test generates pagesize, while the OCI config expects pageSize, so the test fails during config parsing before reaching the HugeTLB cgroup logic.

Yeah, runc uses encoding/json which is case-insensitive, and the test case is wrong.

Fixing in opencontainers/runc#5501. Have you tried running the fixed test case?

Also, have you tried running your own test case before the fix?

@Rajkaran-122

Rajkaran-122 commented Oct 2, 2026 •

Copy link
Copy Markdown
Contributor Author

@kolyshkin sir I tested both cases.

  • My cgroup-resources-hugetlb-reservation-limit regression test passes and verifies both hugetlb.1GB.max and hugetlb.1GB.rsvd.max.
  • I also tested the corrected runc integration case with pageSize instead of pagesize: runc run (hugetlb limits) passes.
  • The test reached crun's HugeTLB cgroup setup, and hugetlb.1GB.rsvd.max was written with the configured value.

I restored the temporary runc test and skip-list changes afterward, and the crun working tree is clean.

@kolyshkin

Copy link
Copy Markdown
Collaborator

Also, have you tried running your own test case before the fix?

@Rajkaran-122 ^^^

@Rajkaran-122

Rajkaran-122 commented Oct 4, 2026 •

Copy link
Copy Markdown
Contributor Author

Also, have you tried running your own test case before the fix?

@Rajkaran-122 ^^^

@kolyshkin sir Yes, I tested my regression test before and after the fix. It failed before the fix and passes after, verifying both hugetlb.1GB.max and hugetlb.1GB.rsvd.max.

Comment thread src/libcrun/cgroup-resources.c Outdated
Comment thread tests/test_cgroup_resources.py Outdated
Rajkaran-122 added a commit to Rajkaran-122/crun that referenced this pull request Oct 7, 2026
- Simplify ENOENT comment in cgroup-resources.c to one line
- Refactor test_hugetlb_reservation_limit to dynamically discover
  available HugeTLB reservation files instead of hardcoding 1GB
- Check for .rsvd.max file presence before running container
- Use specific subprocess.CalledProcessError instead of broad Exception
- Skip with code 77 when reservation accounting is not available

Address reviewer feedback from PR containers#2290

Signed-off-by: Rajkaran Yadav <yadavrajkaran854@gmail.com>
Comment thread tests/test_cgroup_resources.py Outdated
Rajkaran-122 added a commit to Rajkaran-122/crun that referenced this pull request Oct 7, 2026
- Simplify ENOENT comment in cgroup-resources.c to one line
- Refactor test_hugetlb_reservation_limit to dynamically discover
  available HugeTLB reservation files instead of hardcoding 1GB
- Check for .rsvd.max file presence before running container
- Use specific subprocess.CalledProcessError instead of broad Exception
- Skip with code 77 when reservation accounting is not available

Address reviewer feedback from PR containers#2290

Signed-off-by: Rajkaran Yadav <yadavrajkaran854@gmail.com>
@Rajkaran-122
Rajkaran-122 force-pushed the issue-2284-hugetlb-reservation-limits branch from f2428ab to 00f8dbd Compare October 7, 2026 07:09
@Rajkaran-122
Rajkaran-122 requested a review from kolyshkin October 7, 2026 07:55
@Rajkaran-122

Copy link
Copy Markdown
Contributor Author

@kolyshkin Sir PTAL.

@kolyshkin kolyshkin left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please squash your commits

For cgroup v2, write HugeTLB limits to both hugetlb.<size>.max and
hugetlb.<size>.rsvd.max when the kernel supports reservation accounting.
The reservation file may not exist on all kernels, so we silently ignore
ENOENT errors and fall back to usage accounting.

Fixes containers#2284

Signed-off-by: Rajkaran Yadav <yadavrajkaran854@gmail.com>
@Rajkaran-122
Rajkaran-122 force-pushed the issue-2284-hugetlb-reservation-limits branch from 00f8dbd to 85ba6b1 Compare October 10, 2026 07:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

crun leaves supported HugeTLB reservation limits unlimited

2 participants