lifecycle_for_hugepage: Use dynamic page size and improve cleanup

[liang-cong-red-hat]

Key changes:

1. Replace hardcoded page size mapping with dynamic one;
2. Ensure proper hugepage release in teardown;

Test results:

1. x86_64:
   (1/5) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.default_page_size: STARTED
   (1/5) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.default_page_size: PASS (104.81 s)
   (2/5) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.default_hugepage_size: STARTED
   (2/5) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.default_hugepage_size: PASS (109.37 s)
   (3/5) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.1G: STARTED
   (3/5) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.1G: PASS (123.04 s)
   (4/5) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.0: STARTED
   (4/5) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.0: PASS (32.07 s)
   (5/5) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.scarce_mem: STARTED
   (5/5) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.scarce_mem: PASS (34.36 s)

2. aarch64:
   (1/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.default_page_size: STARTED
   (1/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.default_page_size: PASS (87.33 s)
   (2/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.default_hugepage_size: STARTED
   (2/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.default_hugepage_size: PASS (101.12 s)
   (3/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.1G: STARTED
   (3/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.1G: SKIP: The hugepage size '1048576' is not supported on current arch (support: [16777216, 2048, 524288])
   (4/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.2M: STARTED
   (4/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.2M: PASS (96.49 s)
   (5/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.16G: STARTED
   (5/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.16G: PASS (92.80 s)
   (6/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.64K: STARTED
   (6/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.64K: SKIP: The hugepage size '64' is not supported on current arch (support: [16777216, 2048, 524288])
   (7/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.32M: STARTED
   (7/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.32M: SKIP: The hugepage size '32768' is not supported on current arch (support: [16777216, 2048, 524288])
   (8/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.0: STARTED
   (8/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.0: PASS (15.77 s)
   (9/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.scarce_mem: STARTED
   (9/9) type_specific.io-github-autotest-libvirt.memory.backing.lifecycle.memory_hugepage.scarce_mem: PASS (18.83 s)

Summary by CodeRabbit

• Tests
  • Enhanced huge page memory configuration test scenarios with improved parameter handling and expanded coverage for different page size configurations.
  • Refined test cleanup procedures to ensure proper kernel page size restoration during teardown.

[coderabbitai]

Walkthrough

Configuration file hardcodes free_hugepages to zero, while test logic transitions from static page size mappings to dynamic retrieval via memory.get_huge_page_size(), adds early scenario handling, broadens hugepage size coverage to include 1G, and updates teardown cleanup procedures.

Changes

Cohort / File(s)	Summary
Configuration Update libvirt/tests/cfg/memory/memory_backing/lifecycle_for_hugepage.cfg	Replaced dynamic ${set_pagenum} variable references with hardcoded "0" values for free_hugepages in default_hugepage_size and memory_hugepage path blocks.
Test Logic Refactoring libvirt/tests/src/memory/memory_backing/lifecycle_for_hugepage.py	Switched set_pagesize calculation to dynamic memory.get_huge_page_size() retrieval; added early sub_update() for scenario '0'/'default_hugepage_size'; removed aarch64 hard-coded mapping block; extended HugePages_Free assignment to include '1G' scenario; enhanced teardown to record and apply set_pagesize during kernel cleanup.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

The changes blend simple configuration hardcoding with moderate logic refactoring involving dynamic parameter resolution and expanded scenario handling. Review requires understanding the page size mapping strategy and scenario-specific behaviors, but changes remain localized without major architectural shifts.

Poem

🐰 Hugepages dance where zeros now remain,
Dynamic sizes bloom from memory's chain,
From static maps to calls we leap with grace,
1G joins the fold, expanding the space!
Cleanup refreshed—our test suite springs anew,

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title "lifecycle_for_hugepage: Use dynamic page size and improve cleanup" is directly related to the main changes in the changeset. The PR replaces hardcoded page size mapping with dynamic retrieval via memory.get_huge_page_size() and significantly improves the teardown cleanup process by properly recording and using set_pagesize through hp_cfg.set_kernel_hugepages(). Both aspects mentioned in the title align with the primary objectives documented in the PR description and reflected in the code changes. The title is concise, specific enough to convey the core changes, and clearly identifies the component being modified. While the config file changes (literal "0" replacements) are not explicitly mentioned, the title appropriately focuses on the primary architectural improvements in the Python file, which aligns with the instruction that titles don't need to cover every detail.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (2)

libvirt/tests/src/memory/memory_backing/lifecycle_for_hugepage.py (2)

56-60: Good: Dynamic page size retrieval improves portability.

Replacing the hardcoded page size mapping with memory.get_huge_page_size() correctly adapts to different system configurations.

However, remove the unnecessary int() cast on line 60:

-        params['set_pagenum'] = int(math.floor(total_hugepage_mem/set_pagesize))
+        params['set_pagenum'] = math.floor(total_hugepage_mem/set_pagesize)

math.floor() already returns an integer in Python 3.

---

73-80: Remove unnecessary int() cast.

math.floor() returns an integer in Python 3, making the int() cast on line 75 redundant.

-        params['vm_nr_hugepages'] = int(math.floor(total_hugepage_mem/default_hugepage_size))
+        params['vm_nr_hugepages'] = math.floor(total_hugepage_mem/default_hugepage_size)

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 9aa7dea and 1d796be.

📒 Files selected for processing (2)

• libvirt/tests/cfg/memory/memory_backing/lifecycle_for_hugepage.cfg (1 hunks)
• libvirt/tests/src/memory/memory_backing/lifecycle_for_hugepage.py (3 hunks)

🧰 Additional context used

🪛 Ruff (0.14.1)

libvirt/tests/src/memory/memory_backing/lifecycle_for_hugepage.py

75-75: Value being cast to int is already an integer

Remove unnecessary int call

(RUF046)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: Python 3.12
• GitHub Check: Python 3.11
• GitHub Check: Python 3.9
• GitHub Check: Python 3.8

🔇 Additional comments (4)

libvirt/tests/cfg/memory/memory_backing/lifecycle_for_hugepage.cfg (1)

45-45: LGTM! Config aligns with dynamic page size handling.

The hardcoded "0" is correct for the default_hugepage_size scenario, as the Python code now dynamically calculates page sizes via sub_update() at runtime.

libvirt/tests/src/memory/memory_backing/lifecycle_for_hugepage.py (3)

70-71: LGTM! Correctly extends dynamic page size handling.

Including 'default_hugepage_size' in the condition ensures both scenarios that require system-default page sizes call sub_update() for dynamic calculation.

---

84-84: LGTM! Correctly includes '1G' scenario for aarch64.

Adding '1G' to the scenario list properly sets HugePages_Free for 1G hugepage tests, as confirmed by the passing test results.

---

211-218: LGTM! Proper cleanup with correct page size.

Retrieving set_pagesize from params and passing it to set_kernel_hugepages() during teardown ensures hugepages are properly released using the correct page size that was configured during test setup.

[liang-cong-red-hat]

@dzhengfy please help review.

[dzhengfy]

LGTM