Jetson Memory Audit
Audit live Jetson memory usage and verify that reclaimed DRAM is genuinely available.
The skill is primarily read-only, explicitly requires user authorization before drop_caches, and defines host, privilege, and sandbox-visibility boundaries. However, cache dropping still requires root/sudo, the script itself has no interactive confirmation, rollback is limited, and data-flow disclosure is incomplete, so points are deducted.
Instructions, arguments, exit codes, abnormal-visibility handling, and failure messages are fairly clear. However, key dependencies such as snapshot.sh, common.sh, and detect_jetson.sh are not included in the supplied evidence, and no key-path tests are shown; static calibration therefore keeps this below 10.
The audience, triggers, outputs, host/container boundary, and non-fit cases are clearly described, including hand-offs to related skills. Chinese-language interaction is not specified, and operation depends on Jetson host visibility, so points are deducted.
The documentation has useful layering, prerequisites, script descriptions, limitations, error handling, version metadata, and an evaluation report. It lacks the recommended Examples section, the author format fails the stated validator, changelog and maintenance/update ownership are incomplete, and license metadata is inconsistent with the file-level declarations.
The JSON audit, before/after cache-drop deltas, and baseline workflow directly address the core task and prohibit estimation or fabricated values. However, the benchmark dataset is unavailable, reported effectiveness is only 47% and correctness 68%, and static review cannot verify actual script outputs, so points are deducted.
Committed scripts, design notes, evaluation results, and eval definitions provide some auditable evidence. Coverage is limited because the evaluation dataset is unavailable and no key-path test suite or independent reproduction evidence is supplied.
- Before running drop_caches, reconfirm authorization, target host, and operational impact; the skill provides no rollback procedure for the global cache-state change.
- audit.sh depends on snapshot.sh and other helper files not included in the supplied evidence; verify dependency paths and version alignment before deployment.
- Do not treat the benchmark PASS or percentages as independent validation; the report states that the evaluation dataset was unavailable.
- Normalize the license, author metadata, and maintenance-ownership information before publication.
What does this skill do, and when should you use it?
This is a read-only memory auditing skill for NVIDIA Jetson devices, covering DRAM, NvMap, and process memory usage. It runs an audit script that produces a JSON snapshot containing memory totals, available memory, caches, system target, display-manager candidates, NvMap clients, and high-PSS processes. For JetPack versions below 7.2 or L4T versions below r39.0, it explains why memory may remain held after a CUDA workload exits and provides a user-authorized cache-reclamation verification loop. It is best suited to Jetson host operations that require a baseline, an after snapshot, and an actual available-memory delta.
Runs scripts/audit.sh, which invokes jetson-diagnostic/scripts/snapshot.sh and emits a JSON memory snapshot; the snapshot uses live device data for memory, processes, system target, candidate display services, tegrastats, and NvMap. For explicitly authorized cache reclamation, it runs scripts/drop_caches.sh with --mode 1|2|3 and --quiet options, then reports before/after free, available, and cached deltas. It requires comparing memory_kb.available across before and after snapshots rather than estimating reclamation from container size, model size, or a single RSS value.
- A Jetson user needs current memory usage and wants to identify the leading process or NvMap consumer.
- A user stopped vLLM, sglang, Ollama, or another CUDA workload but free -h or tegrastats still reports high usage.
- An operator needs before-and-after baselines to measure the real memory change from a user-approved system adjustment.
- A user needs to inspect the graphical target and display-manager state while handing desktop-service changes to another skill.
- An audit must determine whether the current sandbox can see the Jetson host's /proc, tegrastats, and NvMap data.
What are this skill's strengths and limitations?
- Uses live Jetson device data for memory, processes, tegrastats, system target, and NvMap information.
- Separates point-in-time snapshots from before/after reclamation deltas instead of inferring savings from workload size.
- Addresses the documented CUDA-related memory-retention symptom on older JetPack/L4T releases.
- The cache helper runs sync first and requires authorization before cache dropping.
- Without a before snapshot, the exact amount already reclaimed cannot be recovered from the current state alone.
- NvMap attribution depends on host-visible debugfs access and may require root.
- A sandbox or container without Jetson host visibility cannot provide real memory figures.
- The skill does not disable desktop services, tune model servers, or recommend unsafe boot-time edits.
How do you install this skill?
Install it through the NVIDIA skills CLI:
npx skills add nvidia/skills --skill jetson-memory-audit --yes
The README does not document a separate package or additional version requirement for this skill.
How do you use this skill?
Ask an agent with the skill loaded questions such as “How much memory is in use on this Jetson?” or “Why did memory not free after I stopped vLLM?” Run scripts/audit.sh on the Jetson host, or in a sandbox exposing host /proc, /etc/nv_tegra_release, tegrastats, and process data. Run scripts/drop_caches.sh only after explicit user authorization. To measure reclamation, save an audit baseline, make the approved change, perform any appropriate host-side cache flush, and run the audit again.
How does this skill compare with similar options?
The source does not name a direct competitor or replacement. It explicitly hands desktop-mode planning to jetson-headless-mode and model-server memory tuning to jetson-inference-mem-tune when those cases apply.