Linux asymmetric multiprocessing stack has potential but lacks depth in maintenance and testing

At Embedded Linux Conference Europe 2026, Linux kernel developer Wolfram Sang, who maintains the I2C subsystem, delivered a sobering assessment of the Linux foundations underpinning asymmetric multiprocessing—a design pattern now gaining traction in systems-on-chip. The verdict: the components work, but the ecosystem supporting them is fragile.

What is AMP and how does Linux fit in?#

Asymmetric multiprocessing lets a single chip host both general-purpose Linux application processors and a dedicated real-time core, all sharing a single system image. Communication between these domains relies on mailboxes (which signal when data is ready), shared memory pools, and a protocol stack. As systems grow more complex, coordinating access to shared resources—clocks, power states, and peripherals—becomes critical. Sang highlighted SCMI (System Control and Management Interface) as the emerging standard for Linux to negotiate with a dedicated system-control processor rather than managing every resource directly.

The picture looks simple on paper: a mailbox sends a message, shared RAM holds the payload. In practice, the topology varies wildly depending on firmware assumptions. Sang illustrated how two one-way mailboxes can combine into a single request-response channel, while full bidirectional SCMI can demand four. His Keystone example showed firmware imposing yet another constraint—two unidirectional mailboxes for bidirectional communication, with no separate notification path.

The Linux component stack#

Several Linux subsystems underpin AMP workloads. Remoteproc loads firmware onto remote cores and manages their lifecycle; a firmware binary can declare what memory and devices it needs. Once remoteproc establishes a shared-memory link and provides a callback to "kick" the other processor, RPMsg enables message-passing between processors. Virtio layers in a standardized shared-memory queue mechanism with signaling. (A newer proposal, virtio-over-message transport, would tunnel virtio traffic through a message channel; it remains out-of-tree.)

Maintenance depth shows warning signs#

Sang's analysis of commit history revealed uneven health. The remoteproc core grew from 175 commits at Linux 5.0 to roughly 1,550—steep growth, though it has plateaued in recent years. Mailbox drivers and commits expanded more recently, yet only about four authors contributed more than five patches. : core commits barely moved from 19 to 30 over seven years, while the driver count stayed flat. Sang stopped short of declaring these components broken; instead, he called for more reviewers and testers to shoulder the load.