docs(troubleshooting): add soft memory enforcement mechanics & libvgp… - #741
docs(troubleshooting): add soft memory enforcement mechanics & libvgp…#741ipsitapp8 wants to merge 1 commit into
Conversation
✅ Deploy Preview for project-hami ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ipsitapp8 The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Welcome @ipsitapp8! It looks like this is your first PR to Project-HAMi/website 🎉 |
|
Warning Review limit reached
Next review available in: 42 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdded English and Chinese documentation for HAMi GPU memory enforcement, bypass diagnosis, and verification. Updated troubleshooting links and sidebar navigation to expose the new guide. ChangesGPU Memory Troubleshooting
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/troubleshooting/cuda-memory-enforcement.md`:
- Around line 150-152: Replace the hardcoded /proc/1/maps checks with the
offending CUDA workload/application PID in both the detailed diagnostic and
checklist steps: docs/troubleshooting/cuda-memory-enforcement.md lines 150-152
and 185-185, and
i18n/zh/docusaurus-plugin-content-docs/current/troubleshooting/cuda-memory-enforcement.md
lines 159-161 and 194-194. Keep the expected libvgpu.so mapping guidance
unchanged while ensuring every English and Chinese command targets the workload
PID.
- Line 181: Update the checklist expected results at
docs/troubleshooting/cuda-memory-enforcement.md:181 and
i18n/zh/docusaurus-plugin-content-docs/current/troubleshooting/cuda-memory-enforcement.md:190
to accept CUDA_DISABLE_CONTROL being unset or set to false, matching the
documented enforcement behavior in both English and Chinese.
- Line 189: Update the CUDA troubleshooting guidance at
docs/troubleshooting/cuda-memory-enforcement.md:189-189 and mirror the same
wording at
i18n/zh/docusaurus-plugin-content-docs/current/troubleshooting/cuda-memory-enforcement.md:198-198.
Do not treat missing [HAMi-core] logs as proof that libvgpu.so is not
intercepting calls because LIBCUDA_LOG_LEVEL may suppress them; describe absence
as suggestive only and require a positive process-level check, such as
confirming libvgpu.so is mapped in the offending process.
- Line 29: Update the paragraph around the dlsym interception description in
docs/troubleshooting/cuda-memory-enforcement.md:29-29 and its Chinese mirror
i18n/zh/docusaurus-plugin-content-docs/current/troubleshooting/cuda-memory-enforcement.md:38-38
to state that libvgpu.so intercepts only CUDA/NVML symbols registered in its
explicit hook tables, rather than every cu* or nvml* function. Also update the
matching core-concepts paragraph with the same scope correction; no other
behavior or documentation claims need changing.
- Around line 145-155: Update the CUDA linkage diagnostics in
docs/troubleshooting/cuda-memory-enforcement.md: clarify that ldd only reports
declared dependencies and may miss libraries loaded with dlopen, add inspection
for runtime-loaded CUDA libraries and RTLD_DEEPBIND bypasses, narrow the
“statically linked” conclusion accordingly, and remove the unqualified framework
claim. Mirror the same corrected diagnostic and resolution guidance in
i18n/zh/docusaurus-plugin-content-docs/current/troubleshooting/cuda-memory-enforcement.md
(lines 149-164); both sites require direct changes.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: e184309b-b6af-493e-bb92-e556d38bcecc
📒 Files selected for processing (4)
docs/troubleshooting/cuda-memory-enforcement.mddocs/troubleshooting/troubleshooting.mdi18n/zh/docusaurus-plugin-content-docs/current/troubleshooting/cuda-memory-enforcement.mdsidebars.js
4ea1e0c to
d091988
Compare
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/troubleshooting/cuda-memory-enforcement.md`:
- Around line 159-161: Revise the verification guidance so a mapped libvgpu.so
is described only as preload verification, not proof of enforcement; require a
controlled enforcement test to confirm intercepted symbols. Apply this at
docs/troubleshooting/cuda-memory-enforcement.md lines 159-161 and 195-195, and
mirror the same corrected guidance at
i18n/zh/docusaurus-plugin-content-docs/current/troubleshooting/cuda-memory-enforcement.md
lines 168-170 and 204-204.
- Line 187: Remove the backslash escapes before inline command pipes so the
shell pipelines render and execute correctly: update
docs/troubleshooting/cuda-memory-enforcement.md lines 187 and 191-192, and
mirror the same corrections in
i18n/zh/docusaurus-plugin-content-docs/current/troubleshooting/cuda-memory-enforcement.md
lines 196 and 200-201.
- Line 188: Update the CUDA memory enforcement checklist to use a variable
device index instead of hardcoding device 0: change
docs/troubleshooting/cuda-memory-enforcement.md lines 188-188 and mirror the
same correction in
i18n/zh/docusaurus-plugin-content-docs/current/troubleshooting/cuda-memory-enforcement.md
lines 197-197. Use the CUDA_DEVICE_MEMORY_LIMIT_<index> form, or explicitly
document the single-device assumption.
- Line 179: Update the Resolution guidance in
docs/troubleshooting/cuda-memory-enforcement.md:179 and
i18n/zh/docusaurus-plugin-content-docs/current/troubleshooting/cuda-memory-enforcement.md:188
to require that the read-only hostPath mount for /etc/ld.so.preload exists and
is readable, not writable; remove the write-access requirement while preserving
the hostPath and admission-controller troubleshooting context in both language
versions.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 5da19189-591b-47b2-a200-03e3d64271ff
📒 Files selected for processing (2)
docs/troubleshooting/cuda-memory-enforcement.mdi18n/zh/docusaurus-plugin-content-docs/current/troubleshooting/cuda-memory-enforcement.md
…u.so diagnostic runbook Adds a comprehensive troubleshooting deep-dive page detailing HAMi's soft CUDA-level memory enforcement mechanics via libvgpu.so. Includes a soft vs hard enforcement comparison matrix, 5 documented bypass scenarios with diagnostic commands, a 7-step quick checklist, and Chinese translation placeholder. Signed-off-by: ipsitapp8 <ipsitapp8@gmail.com>
d091988 to
6b41ffd
Compare
|
@rootsongjc @wawa0210 heyy maintainers! please take a look on this pr. |
Summary
Upstream tracking issue: #656 ([LFX Mentorship] Expand HAMi GPU-sharing tutorials, labs, and troubleshooting guides)
This PR adds a comprehensive technical guide and diagnostic runbook explaining how HAMi's soft CUDA-level memory enforcement works, why it can be bypassed, and how to debug each bypass scenario step-by-step.
Changes Made
docs/troubleshooting/cuda-memory-enforcement.md: Explainslibvgpu.sointerception chain, soft vs hard enforcement comparison matrix, 5 concrete bypass scenarios with diagnostic commands, and a 7-step quick checklist.docs/troubleshooting/troubleshooting.md: Adds cross-reference admonition pointing to deep-dive page.sidebars.js: Convertstroubleshootingsingle doc into a category with both pages.i18n/zh/.../cuda-memory-enforcement.md: Adds Chinese translation placeholder with bilingual pending note to ensure clean build link resolution.Verification
npm run lint(Markdownlint)npm run format:check(Prettier)npx docusaurus build --locale en(Static build + link check)Summary by CodeRabbit