add CMA (Contiguous Memory Allocator) enablement test script#298
add CMA (Contiguous Memory Allocator) enablement test script#298vnarapar wants to merge 1 commit intoqualcomm-linux:mainfrom
Conversation
smuppand
left a comment
smuppand
left a comment
There was a problem hiding this comment.
Right now the test is mostly presence + observation. To validate CMA “functionality”, add one or more active functional checks:
A) Validate CMA is actually being used by at least one subsystem (non-invasive)
Check for common multimedia allocations that use CMA:
ION / dma-buf heaps (depending on kernel/userspace)
camera/video drivers that allocate contiguous buffers
Practical checks:
Look for dma_alloc_from_contiguous users in dmesg? (rare)
Check for increases in CmaFree drop after starting a known multimedia test (optional integration)
Extension idea: If media-ctl/camera nodes exist, do a short yavta capture (or your existing camera smoke test) and re-read /proc/meminfo before/after:
If CMA total is non-zero and capture runs, expect CmaFree to fluctuate at least once.
Don’t hard-fail if it doesn’t (drivers may use other paths), but log as INFO.
B) Validate reserved-memory DT looks correct (stronger DT parsing)
Current DT check only counts regions. You can improve by:
Identify nodes with compatible = "shared-dma-pool" and/or linux,cma-default
Report their size, alignment, reusable
Verify at least one CMA pool exists in DT when kernel cmdline doesn’t specify cma=
Implementation detail:
Read /proc/device-tree/reserved-memory/*/compatible, /linux,cma-default, /size, /alignment.
Size properties are binary cells; needs hexdump parsing (doable with od -An -t u4 etc).
C) Validate kernel cmdline CMA overrides
Check /proc/cmdline for:
cma= or cma_pernuma= etc (if relevant)
If present, compare configured size against /proc/meminfo CmaTotal with tolerance.
D) Validate CMA areas and per-area stats from debugfs (more than listing names)
In debugfs CMA directories, there are often files like:
count, pages, used, maxchunk etc (varies by kernel) Your script only lists area names. Enhance to dump key files if present:
total pages
free pages
used pages
alloc failures counters
Make it resilient: “if file exists, print it”.
E) Proactively detect CMA allocation failures in logs (more accurate)
Instead of generic error|fail|warn, look for common CMA failure strings:
cma_alloc: alloc failed
Failed to allocate contiguous memory
dma_alloc_from_contiguous: ... failed
cma: ... allocation failed
This reduces false positives from generic “warn”.
F) Add “pressure” functional test (optional, gated)
If you want a true kernel functional test without requiring multimedia:
Use cma_test module if present (some trees have it)
Or allocate contiguous memory via a small C helper using dma_heap (but that’s userspace and device-dependent)
Or run a workload that triggers hugepage / buddy allocator fragmentation and see if CMA still allocates (hard to do reliably)
|
@ualcomm/qualcomm-linux-testing.triage This pull request has been marked as stale due to 30 days of inactivity. |
Introduce a CMA enablement/validation script that verifies configuration, initialization, runtime behavior, and statistics on Qualcomm platforms. Key capabilities: - Kernel config validation: CONFIG_CMA, CONFIG_DMA_CMA, CONFIG_CMA_DEBUG, CONFIG_CMA_DEBUGFS (mandatory), plus optional CMA sizing and areas. - Memory stats collection: total, free, used, and usage% with size sanity checks (≥ 1 MB). - DT configuration checks: CMA size/alignment and reserved-memory regions. - Runtime verification: dmesg for CMA reservation/alloc/release messages, error/warning detection, and activity counts. - Sysfs/Debugfs interfaces: enumerate `/sys/kernel/debug/cma` areas and report per-area stats; include relevant `/proc/vmstat` counters. - Result artifacts: writes `cma.res` (PASS/FAIL) and logs detailed output to the console. Signed-off-by: Vamsee Narapareddi <vnarapar@qti.qualcomm.com>
|
|
||
| if [ -z "$INIT_ENV" ]; then | ||
| echo "[ERROR] Could not find init_env (starting at $SCRIPT_DIR)" >&2 | ||
| exit 1 |
There was a problem hiding this comment.
Can we write cma.res before exiting here? Right now an early init_env failure exits without producing a result artifact, which is not ideal for LAVA/testkit flows.
| exit 1 | ||
| fi | ||
|
|
||
| if [ -z "$__INIT_ENV_LOADED" ]; then |
There was a problem hiding this comment.
Please use the unset-safe form here: if [ -z "${__INIT_ENV_LOADED:-}" ]; then
Expanding "$__INIT_ENV_LOADED" directly is less robust when the variable is unset.
|
|
||
| log_info "=== CMA Memory Statistics ===" | ||
|
|
||
| if [ -f "/proc/meminfo" ]; then |
There was a problem hiding this comment.
This section reads CmaTotal/CmaFree, but can we also check /proc/cmdline for cma= overrides and compare the configured CMA size against CmaTotal with a reasonable tolerance? That would make the memory validation stronger than pure observation.
|
|
||
| if [ -d "/proc/device-tree/reserved-memory" ]; then | ||
| region_count=0 | ||
| for region in /proc/device-tree/reserved-memory/*; do |
There was a problem hiding this comment.
This DT validation is currently just a reserved-memory node count. Can we strengthen it by parsing the reserved-memory nodes for compatible = "shared-dma-pool", linux,cma-default, and log size/alignment/reusable when present?
Can we reuse the existing check_dt_nodes helper here for the base DT presence check before doing the CMA-specific parsing? Right now this block starts custom DT handling directly, but using the shared helper first would keep orchestration consistent with other test scripts.
| if grep -i -q -E "$CMA_INIT_PATTERN" "$dmesg_tmp" 2>/dev/null; then | ||
| log_pass "CMA initialization messages found in dmesg:" | ||
| grep -i -E "$CMA_INIT_PATTERN" "$dmesg_tmp" 2>/dev/null | tail -n 5 | while IFS= read -r line; do | ||
| log_info " $line" |
There was a problem hiding this comment.
This is fine for logging, but if we want to keep runtime validation stronger, it may help to tie the detected init messages back to DT/cmdline configuration (for example, no cma= override but no DT-backed CMA pool found).
| log_info "CMA allocation/release activity detected" | ||
| alloc_count=$(grep -i -c "cma.*alloc" "$dmesg_tmp" 2>/dev/null || echo 0) | ||
| release_count=$(grep -i -c "cma.*release" "$dmesg_tmp" 2>/dev/null || echo 0) | ||
| log_info " Allocations: $alloc_count" |
There was a problem hiding this comment.
This is still informational only. Can we add one optional active functional check around here — for example, sample CmaFree before/after a gated multimedia workload or cma_test (if available) — so the script validates actual CMA usage and not only dmesg presence/counters?
|
|
||
| # Check for CMA errors/warnings — capture to variable (not a pipe) so pass=false works | ||
| cma_errors=$(grep -i "cma" "$dmesg_tmp" 2>/dev/null | grep -i "error\|fail\|warn" || true) | ||
| if [ -n "$cma_errors" ]; then |
There was a problem hiding this comment.
For this CMA warning/error scan, can we reuse the existing scan_dmesg_errors() helper from functestlib.sh instead of doing a local grep | grep pipeline here?
| cma_area_count=0 | ||
| for area in /sys/kernel/debug/cma/*; do | ||
| if [ -d "$area" ]; then | ||
| area_name=$(basename "$area") |
There was a problem hiding this comment.
This currently only enumerates CMA area names. Can we dump key per-area debugfs stats as well (count, used, maxchunk, and other files if present)? Right now the script says it covers debugfs/per-area stats, but implementation only lists area names.
| fi | ||
|
|
||
| if [ -f "/proc/vmstat" ]; then | ||
| if grep -q "cma" /proc/vmstat; then |
There was a problem hiding this comment.
Similar point here: /proc/vmstat is only being printed. It would be more useful to explicitly log/pass on cma_alloc_success / cma_alloc_fail counters when present, instead of only dumping all CMA-related lines.
| # Core CMA configs | ||
| CORE_CMA_CONFIGS="CONFIG_CMA CONFIG_DMA_CMA CONFIG_CMA_DEBUG CONFIG_CMA_DEBUGFS" | ||
|
|
||
| if ! check_kernel_config "$CORE_CMA_CONFIGS"; then |
There was a problem hiding this comment.
Good use of check_kernel_config here. Since the helper already centralizes /proc/config.gz handling, can we keep all config validation/value lookups routed through shared helpers instead of mixing helper-based checks with separate ad hoc config inspection later?
| if [ ! -d "/sys/kernel/debug" ]; then | ||
| log_info "CONFIG_CMA_DEBUGFS is enabled but debugfs is not mounted" | ||
| log_info "Mounting debugfs" | ||
| if mount -t debugfs debugfs /sys/kernel/debug 2>/dev/null; then |
There was a problem hiding this comment.
There does not seem to be a shared debugfs-mount helper in functestlib.sh today, so this local handling is understandable. But if this pattern is going to be reused by other tests, it may be worth moving the “ensure debugfs mounted” logic into the common library rather than embedding it here.
2 participants
Introduce a CMA enablement/validation script that verifies configuration, initialization, runtime behavior, and statistics on Qualcomm platforms.
Key capabilities:
/sys/kernel/debug/cmaareas and report per-area stats; include relevant/proc/vmstatcounters.cma.res(PASS/FAIL) and logs detailed output to the console.