Skip to main content

TECH VEDA

Corporate on-site training - Submit proposal Pick your modulesSharpen your kernel skills: deep dives, drivers, Yocto, CVEs, careers — updated daily. Read the blog →
Insights

DRAM Shortage: How Much RAM Does Your Embedded Linux Product Need?

The DRAM shortage makes RAM size an engineering decision. Measure what your embedded Linux product uses, and test a smaller variant with mem=.

DRAM Shortage: How Much RAM Does Your Embedded Linux Product Need?

Memory prices are still rising. Micron, a major memory maker, expects supply to be tighter in 2027 and 2028 than in 2026. For an embedded Linux product, the size of the RAM now has a larger effect on unit price than before. Measure what the product uses, and test the smaller memory variant on the hardware you already have. Then plan for the problems that software cannot solve, such as substitute memory parts.

The DRAM shortage now affects the price of common embedded Linux boards. On 2 November 2026, Raspberry Pi raised the price of the 16GB Raspberry Pi 5 by $80, to $385. It also raised the price of the 16GB Compute Module 5 variants by $40. On 30 September 2026, Micron told investors that it expects memory supply to be “much tighter” in 2027 and 2028 than in 2026. This article explains what the DRAM shortage changes for teams that build embedded and edge Linux products. It also shows how to measure the memory a product needs, and it lists what a smaller memory budget cannot fix.

What changed in the DRAM shortage this autumn

This article is based on two statements from the companies involved. Both statements were checked on the companies’ own pages.

The first is the Raspberry Pi announcement of 2 November 2026, written by Eben Upton. It gives three reasons for the new prices. Memory costs have risen steeply over two years. There is no alternative supply for 16GB DRAM. Other component shortages add to the problem. The price of the 16GB Raspberry Pi 500+ did not change. The post also refers to earlier price rises. Upton describes the situation as “difficult but ultimately temporary”. The company says it hopes to reduce prices again when memory costs fall. It also says it is qualifying alternative parts.

The second is the set of prepared remarks for the Micron fiscal fourth quarter of 2026, dated 30 September 2026. Micron reported that DRAM prices rose in the high-teens percentage range in the quarter, and NAND prices rose by about 30%. It expects industry DRAM bit shipments to grow in the low-20s percentage range in 2027 and 2028. It also states that it cannot yet say when supply and demand will return to balance. One line matters directly to embedded buyers. Revenue in the Micron Automotive and Embedded business unit rose 47% from the previous quarter, “driven by higher pricing and higher bit shipments”.

These statements show that embedded customers are paying more per bit. They also show that the supplier gives no date for the end of the DRAM shortage.

Why RAM size is now a design decision

For many products, the RAM size was chosen early and was rarely reviewed. Many teams picked a large variant of a module or a board, so that the software had space to grow. When memory was cheap, the difference between two variants was small compared with the rest of the bill of materials.

During the DRAM shortage, that calculation is different. The price difference between two memory sizes keeps rising. No supplier says when the rise will stop. In this round, Raspberry Pi changed only 16GB products. It gave the lack of alternative supply for 16GB DRAM as one reason. For these products, the largest memory size had both the price rise and the supply problem.

This makes the RAM size an engineering question as well as a purchasing question. Purchasing can negotiate a price, but only the engineering team can say whether the product works with less memory. To answer that question, the team needs measurements, not estimates.

Key insight: During the DRAM shortage, the key question for a design review is how much memory the product uses at its busiest point. The team can measure the answer.

Measure memory use before you choose a RAM size

Three kernel interfaces show the memory use of a running board. All three are documented in the kernel source tree, and the descriptions below were checked against tag v7.3.

The whole system: MemTotal and MemAvailable

The file /proc/meminfo contains two lines that matter here. MemTotal is the usable RAM, which is the physical RAM minus some reserved memory and the kernel code. MemAvailable is the kernel’s estimate of how much memory is available for starting new applications without swapping. The estimate includes free memory and the part of the page cache and slab caches that the kernel can reclaim. Do not use MemFree for sizing. It does not count reclaimable cache, so it makes a system look fuller than it is.

root@raspberrypi5:~# grep -E "MemTotal|MemAvailable" /proc/meminfo

Read MemAvailable at the busiest point of the product’s workload, not after boot. The lowest value you see during a full test run tells you how much margin the product has.

The cost of a shortage: PSI memory pressure

A low MemAvailable value does not by itself show that the product is slow. Pressure stall information (PSI) measures the time that tasks spend waiting for memory. It exists in kernels from 4.20 onwards and needs CONFIG_PSI. If the kernel was built with CONFIG_PSI_DEFAULT_DISABLED, add psi=1 to the kernel command line.

root@raspberrypi5:~# cat /proc/pressure/memory

The file has two lines. The some line gives the share of time in which at least one task was stalled on memory. The full line gives the share of time in which all non-idle tasks were stalled at once. Each line has averages over 10, 60 and 300 seconds and a total stall time in microseconds. The kernel documentation describes a workload that spends a long time in the full state as thrashing. On a product, a full value that stays above zero for long periods in normal operation is a strong sign that the memory is too small. A short rise during a peak load is less serious.

Each service: memory.peak

On a system that uses cgroup v2, each service has its own cgroup. The file memory.peak contains the highest memory use of that cgroup since it was created. It has existed since kernel 5.19. On a systemd image, the cgroup of a system service is under /sys/fs/cgroup/system.slice/.

root@raspberrypi5:~# cat /sys/fs/cgroup/system.slice/systemd-journald.service/memory.peak

The value is in bytes. Read it for each service after a long test run that includes the heaviest use case. Add the values, then add the kernel’s own use and the caches the product needs for acceptable performance. The result is a measured estimate of the memory the product needs. The sum is an upper limit, because the services may not reach their peaks at the same time.

Test the smaller memory variant on the board you have

A team often wants to know whether the product works on the next size down. Often it has only the larger boards. With the mem= kernel parameter, a team can answer that question without new hardware. The kernel documentation describes it as a way to force the kernel to use a specific amount of memory. Testing is the first use case in its list.

Add mem=4G, for example, to the kernel command line in the boot loader, and boot the board. Then confirm the limit took effect.

root@raspberrypi5:~# cat /proc/cmdline
root@raspberrypi5:~# grep MemTotal /proc/meminfo

The command line should contain the mem= value you set. MemTotal should be a little below that value, because it excludes reserved memory and the kernel code. Then run the full test suite and read the three interfaces from the previous section again.

Two limits apply. On arm64, the documentation says mem= limits only the memory covered by the linear mapping, and memory regions marked NOMAP are not affected. The parameter also changes only how much memory the kernel uses. It does not change the memory parts, the number of memory channels or the memory bandwidth. A real 4GB variant can have a different bus width or a different number of chips, so a performance test on mem= is an approximation. A test of whether the workload fits in that memory is reliable.

Key insight: With a mem= boot, you can check whether the workload fits in the smaller memory size before anyone orders the smaller board. The test does not show the speed of the smaller board, because the memory hardware is unchanged.

What the DRAM shortage does not let software fix

Careful measurement and a smaller memory budget reduce the risk. They do not remove it. Several parts of the problem are outside the control of the software team.

The memory type is fixed by the SoC. The memory controller of an application processor supports a fixed set of memory types and sizes. If the supported type is in short supply, software cannot select a different type. Only a different SoC or a different board design can do that.

A substitute memory part is a hardware and firmware change. On most application processors, the boot firmware initialises the DRAM with settings for the specific memory part. A substitute part therefore usually needs new settings, a new boot firmware build and a new qualification run. Raspberry Pi says it is doing this work now. A product team that plans to use a second memory source should plan the same work.

Compressed swap does not remove the limit. A compressed swap device in RAM (zram) can hold cold anonymous memory in a smaller form. The kernel documentation bases its sizing advice on an expected 2:1 compression ratio. However, the compressed data still uses RAM, the compression uses CPU time, and data that is already compressed does not become smaller. The trade-offs are covered in detail in the TECH VEDA article on swap on embedded Linux with zram.

Flash storage is also more expensive. A team might plan to move memory use to storage, for example with swap on eMMC. Micron reported NAND prices up by about 30% in the same quarter, so storage is under the same price pressure as DRAM.

Some workloads need the memory. An on-device AI model needs memory for its weights and its working buffers. If the model does not fit, the options are a smaller model, a quantised model or more memory. Each option is a product decision, not a kernel setting.

Key insight: A second memory source reduces the supply risk of the DRAM shortage, and it is a firmware and qualification project. Start it before the current part is hard to buy, not after.

What to do in the next design review

The following engineering tasks follow from the DRAM shortage.

  1. Record the measured memory use of the product. This means the lowest MemAvailable value, the memory.peak value for each service and the PSI values during the heaviest test.
  2. Boot a current board with mem= set to the next size down and run the full test suite. Record whether it passes and what the PSI values are.
  3. If the product passes on the smaller size, compare the price difference between the two variants. Compare it with the risk of less free memory for future software.
  4. Ask the module or board supplier which memory parts are qualified for each variant, and whether a second source exists.
  5. If a second source is needed, plan the boot firmware change and the qualification test as a project with an owner and a date.
  6. Add memory measurements to the regular test process, so that a new software release that uses more memory is visible before release.

None of these steps depends on a forecast of memory prices during the DRAM shortage. They are worth doing whether the DRAM shortage ends in 2027 or continues after 2028.

Key takeaways

  • Raspberry Pi raised 16GB product prices on 2 November 2026, and Micron expects tighter memory supply in 2027 and 2028 than in 2026.
  • The DRAM shortage makes the RAM size an engineering decision with a larger effect on unit price.
  • Use MemAvailable, PSI memory pressure and memory.peak to measure what the product needs.
  • Use the mem= boot parameter to test a smaller memory size on current hardware, and remember that it does not test memory speed.
  • A second memory source needs boot firmware work and qualification, so plan it early.
Was this worth your time?

Frequently asked questions

Is the DRAM shortage expected to end soon?
Micron expects memory supply to be much tighter in 2027 and 2028 than in 2026. It also states that it cannot yet say when supply and demand will return to balance. Raspberry Pi calls the situation temporary but gives no date.

Which kernel file shows how much memory is free for applications?
MemAvailable in /proc/meminfo. It is the kernel’s estimate of the memory available for starting new applications without swapping, and it includes reclaimable cache, which MemFree does not.

Can I test a 4GB product on an 8GB board?
Yes. Add mem=4G to the kernel command line. This tests whether the workload fits in 4GB. It does not test the speed of a real 4GB board, because the memory parts and their bandwidth are unchanged.

Does zram solve the problem of a smaller memory size?
Not fully. The compressed data still uses RAM, compression uses CPU time, and data that is already compressed does not become smaller.

Why is a second memory source a firmware task?
On most application processors, the boot firmware initialises the DRAM with settings for the specific memory part. A substitute part therefore usually needs new settings and a new qualification run.

Further reading

RB
Raghu Bharadwaj

Founder, TECH VEDA — 20+ years teaching the Linux kernel, device drivers and embedded systems.

Follow on LinkedIn

Get new posts by email

Kernel, embedded Linux and AI-era engineering — a few sharp reads a month. No spam.

We email occasionally and never share your address.