Linux 7.4 will add a new function, cmpxchg_emu_u16(), that emulates the two-byte atomic compare-and-exchange operation on architectures that lack a native instruction for it. The change comes from Paul E. McKenney, a long-time kernel developer, and affects four niche architectures: SH, ARC, C-SKY and Xtensa. In the same pull request, McKenney hints that some systems Linux still supports may soon be dropped.

The key facts about two-byte cmpxchg emulation in Linux 7.4 in 30 seconds

Linux 7.4 adds cmpxchg_emu_u16(), which performs a two-byte cmpxchg() using a four-byte one.
It applies to SH, ARC, C-SKY and Xtensa, which have no native instruction for that operation.
As a result, common kernel code can assume two-byte cmpxchg works on every architecture.
It extends the one-byte emulation McKenney himself introduced in 2024.
McKenney believes some systems without native two-byte stores will soon lose Linux support.

This is plumbing work that administrators will not notice day to day, but it shows how a kernel running on dozens of architectures is maintained: either software emulates what the hardware does not provide, or support for that hardware is eventually removed. Linux 7.4 does the first and anticipates the second.

What cmpxchg does and why size matters

cmpxchg() (compare and exchange) is one of the kernel’s basic atomic operations. It compares the value at a memory location with an expected value and, only if they match, replaces it with a new one, all in a single step that no other processor can interrupt. Locks, counters and lock-free data structures are built on top of it, so it appears throughout the code that handles concurrency.

Most modern architectures offer this operation for several sizes: one, two, four and eight bytes. Some only provide it for four bytes or more. On those systems, common kernel code cannot use a two-byte cmpxchg without first checking which architecture it is running on, which complicates maintenance and can lead to bugs that are hard to spot.

How the emulation works

The technique already exists for single bytes. In 2024, McKenney added cmpxchg_emu_u8() to the kernel, in lib/cmpxchg-emu.c, so that common code could use one-byte cmpxchg on architectures without native support. The method locates the aligned four-byte word that contains the target byte, reads it, builds a new word with only that byte changed and attempts a four-byte cmpxchg on it. If another processor has modified the word in the meantime, the attempt fails and is retried with the new value.

cmpxchg_emu_u16() applies the same idea to two-byte values. In McKenney’s words, the changes emulate “two-byte cmpxchg() in terms of four-byte cmpxchg()” on architectures without native instructions for it. The cost is some performance: an operation that is a single instruction on other CPUs becomes a small loop. Because it only affects architectures that are rarely used in servers, the practical impact is limited.

The main beneficiaries are developers. With this emulation, common kernel code can treat two-byte cmpxchg as safe everywhere, without architecture-specific branches. It is the same approach that was taken for the one-byte case.

The affected architectures and McKenney’s warning

SH (SuperH), ARC, C-SKY and Xtensa are now used mainly in embedded systems and microcontrollers, with little or no presence in servers. C-SKY, a Chinese 32-bit architecture, was merged into the kernel in 2018. At the time, some developers remarked that, with the industry converging on RISC-V, it might be the last new CPU port the kernel would need. That prediction did not fully hold: LoongArch arrived in 2022.

The most notable remark comes at the end of the pull request. McKenney notes that some systems Linux still supports do not even have native instructions to store two bytes, and that “there is reason to believe that these systems will soon no longer be supported by Linux”. He does not say which systems or when, so for now this is an expectation, not a decision. It does fit the trend of recent years, in which the kernel has removed old architectures and processors that few people use and that complicate maintenance of common code. For another look at where kernel development is heading, see how Multikernel aims to run multiple Linux kernels on one physical server without a hypervisor.