dump_guest_memory: Increase timeout for large vmcore dumps #4391
Conversation
WalkthroughTimeouts for guest memory/core dump operations were increased to 1800 seconds in config and test code. Changes: Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Pre-merge checks and finishing touches✅ Passed checks (2 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (3)
🚧 Files skipped from review as they are similar to previous changes (3)
Comment |
|
Test Results: PASS FROM: TO: |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
qemu/tests/dump_guest_core.py (1)
65-65: Inconsistent timeout: crash command should also be increased.The crash command timeout remains at 60 seconds, but
dump_guest_memory.pyline 160 increased it to 1800 seconds for the same operation. Large vmcore files (132 GB) will likely require more than 60 seconds for crash to analyze. This timeout should be increased to 1800 for consistency.Apply this diff to fix the inconsistency:
- output = process.getoutput(crash_cmd, timeout=60) + output = process.getoutput(crash_cmd, timeout=1800)
🧹 Nitpick comments (1)
qemu/tests/cfg/dump_guest_memory.cfg (1)
7-7: Consider a larger safety margin for the timeout value.The timeout increase to 1800 seconds is appropriate for large vmcore dumps. However, based on your PR description (132 GB at 75 MB/s ≈ 1802 seconds), this provides minimal buffer. Consider increasing to 2400 or 3600 seconds to accommodate slower I/O speeds, system load, or compression overhead.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
qemu/tests/cfg/dump_guest_memory.cfg(1 hunks)qemu/tests/dump_guest_core.py(2 hunks)qemu/tests/dump_guest_memory.py(1 hunks)
🔇 Additional comments (3)
qemu/tests/dump_guest_core.py (2)
48-48: LGTM! Appropriate timeout increase for gdb dump generation.The timeout increase from 360 to 1800 seconds is appropriate for generating large vmcore files via gdb.
116-116: LGTM! Defensive timeout increase.The timeout increase to 1800 seconds is safe and consistent. Note that this wait might be redundant since
check_core_file()(line 113) should have already created the vmcore_file synchronously via the gdb command at line 48. However, the defensive check with adequate timeout is reasonable.qemu/tests/dump_guest_memory.py (1)
160-160: LGTM! Good addition of timeout to prevent indefinite hangs.Adding the 1800-second timeout to the crash verification command is appropriate and prevents potential indefinite hangs when analyzing large vmcore files.
|
Depends on: #4390 |
heywji
force-pushed
the
fix_dump_guest_memory_increase_timeout
branch
2 times, most recently
from
9ad7310 to
d91978b
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
qemu/tests/dump_guest_core.py (1)
48-116: Consider making timeouts configurable.The 1800s timeout is now hardcoded in multiple locations. For large values like 30 minutes, consider making timeouts configurable via test parameters to provide flexibility for different hardware configurations or memory sizes.
For example, you could add to the params section:
gdb_timeout = int(params.get("gdb_timeout", 1800)) crash_timeout = int(params.get("crash_timeout", 1800)) vmcore_wait_timeout = int(params.get("vmcore_wait_timeout", 1800))Then use these variables in the respective locations instead of hardcoded values.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
qemu/tests/cfg/dump_guest_memory.cfg(1 hunks)qemu/tests/dump_guest_core.py(4 hunks)qemu/tests/dump_guest_memory.py(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- qemu/tests/dump_guest_memory.py
- qemu/tests/cfg/dump_guest_memory.cfg
🔇 Additional comments (3)
qemu/tests/dump_guest_core.py (3)
48-48: Timeout increase is appropriate for large memory dumps.The increase from 360s to 1800s is well-justified by the test results showing operations take 400-438 seconds for 126 GB memory VMs. This aligns with the PR objective to handle ~132 GB vmcore files.
65-65: Timeout increase is consistent and necessary.The increase from 60s to 1800s is necessary for analyzing large vmcore files (~132 GB) and maintains consistency with the other timeout changes in this test.
116-116: Timeout increase is appropriate and consistent.The increase from 60s to 1800s for waiting for the vmcore file to exist is necessary for large vmcore files and maintains consistency with the other timeout changes throughout this test.
Remove process.TimeoutError from exception handling, as it doesn't exist in avocado.utils.process module. Signed-off-by: wji <[email protected]>
Increase dump timeout from 90s to 1800s (30 minutes) to handle large vmcore files (~132GB). The original timeout was too short for VMs with 126GB memory, causing truncated vmcore files. With 30-minute timeout, even at 75MB/s disk I/O speed, 132GB dumps should complete successfully. Signed-off-by: wji <[email protected]>
heywji
force-pushed
the
fix_dump_guest_memory_increase_timeout
branch
from
d91978b to
d4d5e01
Compare
1 participant
Increase dump timeout from 90s to 1800s (30 minutes) to handle large vmcore files (~132GB). The original timeout was too short for VMs with 126GB memory, causing truncated vmcore files.
With 30-minute timeout, even at 75MB/s disk I/O speed, 132GB dumps should complete successfully.
ID: 4239
Signed-off-by: Wenkang Ji [email protected]
Summary by CodeRabbit