The 32GB Illusion: What Modalix Memory Actually Looks Like

Your DevKit ships with 32GB of LPDDR5. `free -h` will show you about 11. Here's where the other 21GB goes, and why it matters for every pipeline you deploy.

Run free -h on a fresh Modalix DevKit and you'll see roughly 11GB of total memory. Check the spec sheet and it says 32GB LPDDR5. Neither number is wrong - but if you don't know why they disagree, you'll misjudge how much headroom your pipeline actually has, and you'll misdiagnose the failures that show up when you run out of it.

The short version: 16GB is permanently walled off for the MLA's tensor memory, and it never shows up in Linux memory tools at all. Another ~2GB is consumed by boot-time reserved regions, on-chip memory, and firmware. What's left over - about 11–12.5GB - is what Linux, and your applications, actually get to use. This piece walks through that split, what each region is for, and the concrete failure modes each one creates when you push past it.

1. The Physical Split: 32GB → 11GB

The 32GB is real - it's LPDDR5-6400 across a 128-bit bus, giving 102.4 GB/s of peak bandwidth. But that physical pool is carved up at boot time before Linux ever gets a look at it. Here's the breakdown, largest region first:

2. Deterministic Inference: Why the DMS Is Walled Off

The 16GB DMS isn't wasted - it's the mechanism that makes MLA inference deterministic. Model weights and scratch space live in the DMS and stream directly into the MLA tiles' internal SRAM, completely bypassing the Linux memory bus and its scheduler. That's what lets the MLA hit consistent, predictable latency at batch size 1: it isn't competing with your applications for memory bandwidth or fighting page cache eviction.

The tradeoff is that this memory is invisible to every standard Linux diagnostic. free -h, /proc/meminfo, top - none of them see it. The only way to observe DMS usage is the vendor tool:

# Live MLA memory usage (ASCII graph)
sima-cli mla meminfo

3. The CMA Ceiling: Your Real Constraint

Of the memory Linux can see, the 1.8GB Contiguous Memory Allocator (CMA) region is the one most pipelines actually bump into. CMA is where camera frames, ISP output, and MLA I/O buffers get allocated - and unlike ordinary heap memory, CMA has to be physically contiguous, so it can't just spill into general RAM when it's full.

# Check current CMA usage
grep -i cma /proc/meminfo

4. No Swap, No Safety Net

SwapTotal: 0 kB. There's no swap configured on the DevKit, which means Linux is overcommitting memory against a hard 50% CommitLimit with nothing behind it if that limit is exceeded.

5. Watch Shared Memory as Your Earliest Pressure Signal

Because there's no swap to give you warning, the earliest practical indicator of memory pressure is watching /dev/shm/mlashmdata growth alongside free -h over time. Steady growth in shared memory usage without a corresponding drop in workload complexity is usually the first sign something is leaking or accumulating before an OOM event actually hits.

# Quick pressure check
ls -la /dev/shm/
df -h /dev/shm

6. Model Size on Disk vs. Model Size in Memory

One more distinction worth internalizing: NVMe storage footprint and DMS memory footprint are not the same number, and they don't behave the same way. Compiled CNN models (around 19GB on NVMe in a typical LLiMa + vision setup) stay resident in the DMS for as long as their pipeline is active. LLiMa (LLM) models, which can run to 31GB on NVMe, instead stream from NVMe into the DMS on demand - they don't need to fully reside in memory at once the way a CNN's weights do.

Quick Reference: Diagnostic Commands

The commands below cover the checks referenced throughout this piece, grouped by what they tell you.

# System memory (the ~11GB Linux partition)
free -h
cat /proc/meminfo


# CMA-specific (the 1.8GB ceiling)
grep -i cma /proc/meminfo


# Boot-time partition log (where every region got carved out)
dmesg | grep -i -E "reserved|cma|memblock"


# MLA / DMS usage (invisible to everything above)
sima-cli mla meminfo
neat --json

All findings in this piece were verified via live serial console on a Modalix DevKit running firmware 2.1.2_master_B3369, NEAT Core 0.2.2.