Memory-optimization measurements: full branch vs audited subset

Public edition, 2026-07-20. This is a trimmed copy of an internal report: internal cross-references and the analysis of one unrelated defect (tracked separately) are removed. All measurements, procedure details, and provenance identifiers are unchanged.

What was measured, and why

SoftAtHome's memory-optimization work for prplware was delivered as a set of component branches based on prplOS 4.2.0. In a separate commit audit, every one of the branch set's 1,037 commits was classified twice by independent reviewers, with each disagreement settled against the full diff. The audit's conclusion: 117 component commits (90 memory optimizations plus 27 build and API dependencies) and 9 prplOS-side commits carry the actual memory work, while the other 920 commits are unrelated features, CI changes, and packaging churn.

This report answers the follow-up question: do images built from only those audited commits (the "surgical" subset) deliver the same memory savings as images built from the full branches? The comparison ran on two bases: prplOS 4.2.0, where the optimization branches originated, and current latest-24.10.

Headline results

On 4.2.0, the subset delivers the full branch's savings. Vanilla (M0) runs at 178,514 KiB of userspace memory; the full branch (M1) reduces that by 9,551 KiB, and the subset (M2) by 9,943 KiB, which is 104.1% of the full branch's reduction. The small overshoot is within the per-boot spreads and is not claimed as a win on its own.

On latest-24.10, the subset beats the full branch. The subset (M4) reduces memory by 5,146 KiB against vanilla (M3); the full branch (M5) reduces it by only 1,631 KiB, leaving the full-branch image 3,515 KiB heavier than the subset image. On this base, the commits the audit classified as unrelated cost memory rather than saving it. One caveat applies to M5 and is noted in the process comparison below.

How the measurements were taken

Every image ran in the same QEMU/KVM virtual machine with 512 MiB of RAM, booted three times, with 180 seconds of settle time before capture. Two metrics were recorded:

• Userspace PSS: the sum of every userspace process's proportional set size, i.e. its resident memory with shared pages split evenly between the processes that use them. Lower is better.
• MemAvailable: the kernel's estimate of memory available to new workloads before swapping. Higher is better.

All figures are medians over the three boots, with the spread between the best and worst boot alongside. The measurement procedure, test list, and virtual-machine shape were identical, byte for byte, at all six points.

One acquisition note: the CI job for M1 (14922716187) failed because a source tag had been deleted upstream, so M1 was rebuilt locally from that job's retained CI configuration, which was verified byte-identical.

The other median meminfo values were:

Per-process comparison on 4.2.0

The totals break down by process as follows, using the subset image's top 20 processes by memory. Deltas are signed KiB; negative means less memory used.

The firewall and netmodel-client reductions reproduce or slightly exceed the full branch, and the rest of the subset's top 20 stays close to it. Two larger differences have known causes in how the subset was selected:

• unbound is 2,030 KiB above M1 because the Unbound work is a separate track that was not part of the audited optimization set (the Confluence backport inventory also lists it separately). The subset image keeps the vanilla Unbound footprint.
• gmap-client is 950 KiB above M1 (it falls outside the top-20 table). The audit kept no gmap-client commits, because that component's changes on the optimization branch were feature, startup, or packaging work rather than steady-state memory savings. The subset image keeps the vanilla 4.2.0 process shape instead of importing them.

Per-process comparison on latest-24.10

The same breakdown for latest-24.10: vanilla M3, full branch M5, subset M4, and all three deltas.

The dominant reductions are shared by the full branch and the subset: firewall (-2,404 and -2,396 KiB), netmodel-client (-1,167 and -1,136 KiB), and ubusd (-316 and -348 KiB). Their direct M4−M5 deltas are only +8, +31, and -32 KiB. M4 is also 139 KiB below M5 in gmap-server and 26 KiB below in hosts-manager, matching the selected gMap and hosts work. tr181-device (-312 KiB) and tr181-dynamicdns (-200 KiB) are the largest other M4−M5 reductions; both have retained accessor-conversion commits in the subset.

Two comparisons need explicit qualification:

• unbound is effectively identical in M5 and M4 (+9 KiB). The audit excluded the separate Unbound track, and a later source review found the full branch's mod-dns-unbound pin content-free or already upstream, so there is no latest-24.10 Unbound penalty to explain.
• gmap-client is structured differently on the two sides (the full branch splits it into separate module processes), and the M5 side of the comparison carries an unrelated service-registration defect, tracked separately. The per-row delta therefore understates rather than overstates the subset's result. This is the caveat referenced in the headline results.

Because the full branch reduces latest-24.10 memory by only 1,631 KiB while the subset reduces it by 5,146 KiB, a "share of the reduction recovered" figure computes to 315.5% and is not meaningful on this base; it is recorded as informational only. The direct comparison stands: the subset image is 3,515 KiB lighter in PSS and 3,224 KiB better in MemAvailable than the full-branch image.

Functional test parity

Alongside the memory numbers, every image ran the same seven functional tests from the prplOS cram suite (cram replays a recorded shell session and diffs the output). These runs check parity: an optimized image must not change any test result relative to its own vanilla baseline. Absolute pass rates are a property of the baselines and of the reduced test environment described below, not of the optimization work; both baselines fail several of these tests, and what matters is that the optimized images fail exactly the same ones, in the same way. Empty output or a missing or invalid test-result file counts as a harness error, and the results below come from parsed xUnit files.

One correction was needed along the way: the first M4 test run showed one extra failure because the chosen prplOS test fixture still contained an expectation line produced by a feature commit the audit had dropped. That single line was removed, the rebuilt image came out byte-identical, and the final run above matches M3 exactly. No expectation belonging to selected behavior was weakened.

All accepted runs of the subset images reached steady state with dropbear, ubusd, amxrt, and the Ambiorix plugins running; M4 additionally shows gmap-server running. The captured evidence scans show no oops, kernel panic, out-of-memory kill, or segmentation fault on any accepted subset run. The post-test failure and nine cthulhu assertion messages appear identically in the vanilla baselines; they are pre-existing behavior, not something the subset introduced.

The test environment is QEMU user-mode networking with a single NIC, so the interfaces eth1, br-guest, and br-lcm do not exist in the guest. Firewall, QoS, and the post test therefore run with reduced scope, and their value here is output identity between baseline and optimized images rather than full functional coverage. This limitation applies equally at all six points.

Dependency and adaptation ledger

Building the subset surfaced a handful of commits that the audited picks need but that the audit had not selected, for example an API function a retained commit calls. Every such addition is listed here with its reason, so the subset's exact content stays fully accounted for and the set could not grow quietly.

Every item has exact commits, build evidence, and rationale in the internal campaign records. Images from the intermediate failed builds were never measured.

Cross-check against the backport inventory

Confluence page 2238382515 (version 9, "2026-07-10: Memory (Backports, Future Enhancements)") lists the intended backport areas. It was fetched read-only after the subset was frozen and used as a completeness cross-check, not as a source of new commits.

Provenance and limitations

• M0 and M3 are vanilla artifacts as released. M5 is the full-branch latest-24.10 artifact from successful CI job 15421624536 at revision 9093d9434baf546930f12e1631072301e232d51f. M1 is the locally built substitute for failed CI job 14922716187, built from that job's retained, byte-identical CI configuration and the source of the upstream-deleted libsahtrace tag.
• M2 and M4 are local builds from pinned prplOS and feed bases. All source overrides resolve to their recorded manifests. moca-manager is not part of the x86 image, so its override was verified through its prepare step on both bases.
• The subset is the keep verdict of the dual independent commit audit: 117 component commits (90 direct memory optimizations plus 27 infrastructure dependencies) and 9 prplOS-side commits.
• All numbers are three-boot medians with spreads, measured in one specific virtual-machine shape; they support the comparisons made here and are not universal performance claims. No numeric pass/fail threshold on memory was set for this work.