Igalia says the kernel can handle x86 atomics more than 5x faster than FEX does

An unaligned atomic instruction raises a SIGBUS on Arm64 and the process is terminated, where x86 runs the same operation without complaint, and that is the instruction-level reason some translated x86 games die outright on Arm hardware. An Igalia engineer told the Linux Plumbers Conference on October 5 that handling the fault inside the kernel is "more than 5x faster" than the way the FEX emulator traps it in userspace now.

Valve's own Steam Frame packaging, from its unboxing video. Credit: Valve. Image: Valve

The talk is listed by the conference as "Emulating x86 atomics on arm64", presented by André Almeida of Igalia in a 30 minute slot in the Gaming on Linux microconference at the Prague Congress Centre, and the motivation he opens on is Steam Frame, which puts Windows x86 games on a Linux Arm64 device. The 19 slide deck is published on the contribution page and was read at 21:02 UTC on October 8.

Arm64 refuses an instruction x86 waves through

Both architectures allow simple memory instructions on unaligned addresses, the deck says. The difference is the atomic ones: "x86 allows it atomic instructions, while ARM64 doesn't", and "Calling an unaligned atomic instruction in ARM64 raises a SIGBUS exception". The abstract puts the awkward part plainly: "we can't modify their source code to avoid unaligned atomic operations."

Emulation makes more of these instructions rather than fewer. x86 has a strong memory model and Arm64 a weak one, so, in the deck's words, "FEX uses sync instructions (barriers, LL/SC, atomics) to get stronger memory ordering. This creates much more 'atomics' instructions than the original code."

FEX handles the fallout in the same userspace stack that puts Windows games on Arm64 through Proton, trapping the SIGBUS itself. "All this context switch is costly: our experimental work shows that is more than 5x faster to do it directly on the kernel side," the deck says. That is Igalia's own experimental figure and a comparison of two ways of handling one fault, not a frame rate and not a game result.

Split locks are the case with no clean answer

The deck poses the next part as a question and answers it in one word: "Guess which application uses split locks? Games!" A split lock is an atomic operation that straddles two cache lines, which x86 permits and Arm64 has no instruction for. The hardware pays for it: "The hardware issues some kind of 'bus lock' that blocks a whole cache", which "Adds latency to all unrelated tasks", and Linux carries a mitigation so that it cannot be used to stall a machine.

Arm's own extensions do not close the gap. The deck credits FEAT_LRCPC and its successors on Armv8.3 and later with helping emulate x86's memory ordering, and notes that "Apple Silicon implemented full TSO emulation on hardware", but says the extensions "can't solve one corner case: the split locks".

Nor is there an obvious workaround in software. "There's no simple way to lock two cachelines", the deck says, because "Atomic instructions can't cross a cacheline", and splitting a 64-bit compare-and-swap into two 32-bit ones lets another thread interleave. The deck works through the permutations and lands on a return value it labels "Abnormal result, memory tearing".

The talk ends on questions, not a patch

The closing slide is headed "Discussion points" and asks whether to halt every other CPU while one of them executes the pair, whether to "Have a Giant Lock in userspace?" and, flatly, "Should mainline support this kind of usecase?" Nothing in the deck claims the split lock case is solved, and the session was booked as a discussion.

None of this says a particular game falls over, and the deck names none. What it does supply is the instruction-level reason a translated x86 game on an Arm64 headset can die rather than merely run slowly. Where a developer has gone to the trouble of a native build, as Wube did for Factorio's Arm64 version, the whole question disappears.