Igalia Revives FUTEX Syscalls to Boost Valve's ARM64 Gaming Push
Igalia updates new FUTEX syscalls for Linux to support Valve's ARM64 gaming and improve FEX efficiency.
Work to extend fast userspace mutual exclusion in the Linux kernel has resumed. Open-source consultancy Igalia has posted a revised version of a new set of FUTEX-related system calls. The aim is to support Valve’s ARM64 strategy and improve the Steam Play environment. According to reporting by Phoronix’s Michael Larabel, the move is directly linked to improving the efficiency of the FEX emulator.
This article is based on Phoronix (All Rights Reserved). It relies on fair quotation under Article 32 of Japan’s Copyright Act. The original text states to the following effect.
Igalia has been working to address shortcomings of the existing get_robust_list / set_robust_list with these new versions to better align with the needs of FEX-Emu and other emulation layers.
The targets are get_robust_list2 and set_robust_list2. This is the first update since late November 2025, adapting the work to the latest mainline kernel. After addressing race conditions, it also accounts for changes around the virtual dynamic shared object. As Valve diversifies its handheld and stationary devices, groundwork on the kernel side is advancing in parallel.
Steam Frame and ARM64 Strategy
Valve is exploring offering Steam Play on instruction sets beyond x86. Igalia’s work has continued since 2025. The goal is to run game assets built for x86 and x86_64 on ARM64. At the center of this is the FEX emulator. FEX handles instruction translation and call mediation, enabling reuse of existing assets.
The device referred to as Steam Frame is seen as a concrete example of this vision. It calls for a handheld design using highly efficient chips to balance battery life and heat generation. ARM64 chips have an advantage in power efficiency. For gaming, parallel execution of rendering and physics calculations is essential. The load of synchronization across multiple threads cannot be ignored.
Valve’s hardware rollout is not limited to one-off prototypes. As shown in Valve Acknowledges Steam Machine Overheating Warning and Early Malfunction, Moves to BIOS Fix, the company continues to address defects in its own devices and update system software. Its stance of operating hardware, system software, and the distribution platform as one is clear. ARM64 support lies on that extension. Carrying over its library without depending on specific chips is the challenge.
Steam Play has worked with Proton to run Windows assets on Linux. On ARM64, differences in instruction sets are added. Gaps arise that a compatibility layer alone cannot absorb. Optimization reaching into the kernel’s synchronization mechanisms becomes necessary. This FUTEX extension is part of that effort.
Limitations of Existing Syscalls and Goals of
the New Design
FUTEX stands for fast userspace mutex. It is a mechanism with the kernel at its core for mutual exclusion between threads. It combines a fast path in userspace with wait control in the kernel. It reduces context switches and prevents parallel processing from plateauing. It is especially important for latency-sensitive uses such as gaming and audio processing.
A robust list is a mechanism that guarantees lock release when a thread terminates abnormally. The kernel detects locks held at termination and notifies waiters. get_robust_list and set_robust_list are the existing interfaces. Runtimes and execution environments use this list to recover state. It serves as a safety device to prevent cascading hangs on failure.
The existing interfaces date from an earlier design era. They do not fully anticipate mixing of 32-bit and 64-bit or coexistence of different application binary interfaces. In emulation layers, word size and configuration differ between guest and host sides. This causes discrepancies in interpreting the list, making accurate recovery difficult. On the performance side, extra copying and checks occur.
The list2 variants aim to ease this limitation. The new version extends the format of the list and the retrieval procedure. It enables configuration and identification aligned with the needs of emulation layers. It retains generality so layers other than FEX can also use it. The policy is to develop it as a common kernel feature rather than for a specific product. As a consultancy, Igalia is balancing multiple interests.
Race Condition Fixes and VDSO Adaptation
This revision is the first update since late November of last year. The focus is keeping up with the mainline kernel. It includes adaptation to changes involving the virtual dynamic shared object. That mechanism executes frequent operations such as time retrieval without transitioning to the kernel. Changes to call numbers or settings ripple across the whole system. Lagging behind creates unverifiable differences.
The reason updates stalled was addressing race conditions. These are inconsistencies that occur when multiple threads update the list simultaneously. They are the type of defect with low reproducibility that takes time to verify. Igalia prioritized isolating and fixing this issue. The revised version also includes code cleanup and structural improvements. In Phoronix reporting, Michael Larabel notes the code improvements and adaptation to the latest kernel.
The submission was published as a patch series via kernel developer mailing lists. Whether it will be merged into mainline will be decided after review and testing. It is not at the stage for immediate inclusion in a stable release. Distributions may still pick it up on their own. Valve also has the option of adopting it early in kernels for its own devices.
The development process is highly open. Anyone can obtain and verify the patches. Cross-checking with automated testing and static analysis is progressing. Backing race-condition fixes with stress testing is essential. Load testing on real hardware and reproduction testing in virtual environments proceed in parallel. The quality assurance procedure is the same as in normal kernel development.
Ripple Effects on Emulation Layers
FEX absorbs differences between guest applications and the host kernel. The efficiency of translating synchronization primitives determines overall performance. Faster, more accurate retrieval of robust lists reduces context-switch losses. This leads to more stable frame rates and lower input latency. It is an area that shows up as improved perceived quality.
Spillover to other emulation layers is also expected. Sandbox environments and compatibility layers face similar challenges. Lock management when combining runtimes with different word sizes is a common difficulty. If provided as a common kernel-side feature, each layer will no longer need its own workaround. Maintenance burdens will lessen and bugs will be consolidated. It will raise the floor for the ecosystem as a whole.
The significance of ARM64 handhelds lies in power efficiency and heat suppression. Kernel-side efficiency affects battery life. Reducing wasteful waits and retries also directly curbs heat generation. The difference becomes pronounced in small devices with little cooling headroom. Improvements in system software expand freedom in device design.
The remaining step is building consensus in review. Adding interfaces is conditional on maintaining backward compatibility. Existing applications and runtimes must not be broken. Naming and numbering policy will also be at issue. Documentation and test code will determine acceptance. The timing of a mainline merge depends on review progress.
Editorial Opinion
On short-term impact. This revision is an update at the review stage and will not be merged into a stable release immediately. Over the next three to six months, testing by FEX developers and distribution maintainers will likely take center stage. Valve may also conduct early verification in kernels for its own devices. Whether bug reports for compatibility layers decrease will be the near-term indicator.
On the long-term view. If Steam Play on ARM64 reaches practical usability, dependence on x86 will likely decline. Design room for handheld gaming devices and power-saving stationary machines will expand. If developed as a common kernel feature, other emulation layers will also benefit. Carrying libraries across instruction sets looks set to become a competitive factor for distribution platforms.
Questions from the editors. How should we assess the increased kernel maintenance burden as the cost of adding interfaces. How far should public kernel development accommodate a specific company’s hardware strategy. Is there a shared yardstick for balancing performance and maintainability. We believe these issues should be discussed separately from acceptance of the code.
References
- “New FUTEX Syscalls Back To Being Worked On For Helping Valve’s ARM64 Gaming Ambitions”, by Michael Larabel — Phoronix, 2026-09-25T22:42:16.000Z (ARR)
- Source URL: https://www.phoronix.com/news/FUTEX-Robust-List2-Syscalls
Frequently Asked Questions
- What is FUTEX
- It is a fast userspace mutual exclusion mechanism. It combines fast handling in userspace with wait management in the kernel. It streamlines synchronization across multiple threads and is used in latency-sensitive applications such as gaming.
- What improvement does robust_list2 aim for
- Easing the limitations of the existing robust-list interfaces. It aims for accurate lock recovery in environments with differing word sizes and application binary interfaces. Format extensions aligned with the needs of emulation layers such as FEX are central.
- What changed in this update
- Adaptation to the latest mainline kernel and code improvements. It addresses changes around the virtual dynamic shared object. After resolving the race conditions that caused the stall, it has been reposted for review.
Comments