AMDGPU maintainer Alex Deucher sent two patch series to the Linux kernel mailing list on Friday, August twenty first, 2026, adding support for Ultra Accelerator Link. The first is 95 patches and roughly seven thousand lines, covering core infrastructure plus the AMDGPU driver integration. The second is three patches carrying the userspace IOCTL interface and documentation. UALink is the open scale up fabric for connecting accelerators inside a pod, specified for up to 1,024 devices in one domain, and it is the industry answer to Nvidia's NVLink. The interesting part is not the wire protocol. It is that the kernel now has to manage remote memory it does not own.
The short answer
AMDGPU maintainer Alex Deucher posted two UALink series to the kernel mailing list on Friday, August twenty first, 2026. The first carries 95 patches and about seven thousand lines of core infrastructure plus AMDGPU integration, including Network Physical Address partitioning and remote TLB shootdowns for memory that moves. The second adds three patches with the userspace IOCTL interface and documentation. UALink is the open scale up fabric specified for pods of up to 1,024 accelerators.
Most interconnect enablement in the kernel is a driver, a few queues and a lot of error handling. This one is bigger than that, and the reason shows up in the memory management code rather than in the transport.
Two series, one fabric
Alex Deucher, who maintains AMDGPU, posted both series on August 21. The first is the substantial one: 95 patches, roughly seven thousand lines, adding the core kernel infrastructure for Ultra Accelerator Link together with the AMDGPU driver integration. The second is three patches that expose the IOCTL interface to userspace and add documentation for how memory sharing across a pod is meant to be driven.
UALink itself is an open standard developed through a consortium whose members include AMD, Broadcom, Intel, Google and Microsoft. It is a scale up fabric for connecting accelerators inside a pod, specified to link up to 1,024 devices in a single domain.
Scale up is not scale out
The distinction is the whole point and it is easy to blur.
A scale out fabric moves messages between nodes. Ethernet and InfiniBand are scale out: software decides to send something, the fabric delivers it, and the receiving side decides what to do with it. The programming model is explicit communication, and the latency budget is measured in microseconds.
A scale up fabric presents remote memory as memory. A GPU issues an ordinary load or store against an address, and the fabric resolves it to physical memory that happens to live on a different device in the rack. There is no send, no receive, and no copy. That is what NVLink does inside an Nvidia pod, and it is what UALink is specified to do without being tied to one vendor.
PCIe can already do peer to peer transfers between devices, so this is not a new capability in kind. It is a difference in bandwidth, latency and device count large enough that the software model changes: with PCIe peer to peer you stage data, with a scale up fabric you address it.
The hard part is memory that moves
The kernel side of this is where the patch count comes from.
The series introduces partitioning of Network Physical Address space across the accelerators in a pod, so a load or store from one device resolves to the correct physical memory on another. It handles authorisation for exporting a memory range from one device and importing it on another, because letting any device in a pod address any other device's memory without a permission model would be an obvious mistake.
Then there is the part that generates most of the complexity. Accelerator memory is not pinned in place. The TTM memory manager evicts buffers under pressure, and MMU notifiers fire when userspace mappings change underneath. When memory moves, every importer that cached an address translation for it is now holding a translation that points at the wrong physical location.
The series answers this with remote TLB shootdowns on the exporter, triggered on TTM evictions and MMU notifier callbacks, so importers invalidate their cached translations before the memory relocates.
Anyone who has debugged a stale TLB entry on a single machine will recognise the failure mode, and will also recognise that extending it across a fabric makes the window wider and the debugging much worse. Getting this right in review is more important than getting it merged quickly.
What to expect next
There is no merge target attached to these series, and it would be unusual for something this size to land in the cycle it was first posted. Ninety five patches touching core infrastructure plus a major driver pulls in review from more than one subsystem, and the memory management interactions in particular will get read closely.
The realistic reading is that this is the opening of upstream review, not a feature to plan around. What it does establish is that the enablement is happening on the public mailing list rather than in a vendor tree, which is the difference between a fabric your distribution kernel eventually supports and one that requires a specific vendor stack forever.
For most readers this changes nothing operationally. If you plan capacity for training or large scale inference, though, the existence of a credible open scale up fabric with upstream kernel support is a supplier question, not a performance question, and it is the kind that tends to matter more over a three year hardware cycle than a benchmark delta does.
Sources and further reading
- AMD Posts Massive Patch Series For Enabling UALink In The Linux Kernel, Phoronix, August 21, 2026
- Ultra Accelerator Link is an open-standard interconnect for AI accelerators, UALink Consortium
Frequently asked questions
What is UALink and how does it differ from PCIe or Ethernet?
Ultra Accelerator Link is an open standard scale up interconnect for accelerators inside a single pod, developed through a consortium that includes AMD, Broadcom, Intel, Google and Microsoft. The distinction that matters is scale up against scale out. Ethernet and InfiniBand are scale out fabrics: they move messages between nodes, and software explicitly sends and receives. UALink is a scale up fabric that presents remote accelerator memory as memory, so a GPU issues ordinary load and store instructions against an address that physically lives on another device. PCIe can do peer to peer transfers, but not at the bandwidth, latency or device count UALink targets.
What do the two patch series actually contain?
The first series is 95 patches and about seven thousand lines. It adds the core kernel infrastructure for UALink alongside the integration into the AMDGPU graphics driver, including the machinery for partitioning Network Physical Address space across the accelerators in a pod so that direct load and store operations resolve to the right device. It also handles authorisation for exporting and importing memory between devices. The second series is three patches that expose the IOCTL interface to userspace and add the documentation describing how memory sharing between GPUs in a pod is meant to be driven.
Why are remote TLB shootdowns part of this?
Because remote memory can move. When one GPU imports a range of another GPU's memory, the importer caches address translations for it. If the exporting device then relocates or evicts that memory, through a TTM eviction or an MMU notifier firing, every cached translation pointing at the old location is stale and would resolve to the wrong physical memory. The series therefore issues remote TLB shootdowns on the exporter so importers invalidate their translations before the move completes. It is the same correctness problem as a multiprocessor TLB shootdown, extended across a fabric rather than across cores.
When could this land in a released kernel?
There is no merge date, and it would be unusual for a series this size to land in the first cycle it is posted. Ninety five patches touching core infrastructure and a major driver draws review from more than one subsystem, and the memory management interactions in particular tend to attract careful scrutiny. Treat this as the start of upstream review rather than a feature you can plan a deployment around. What it does confirm is that AMD is building the enablement in the open on the mailing list, which is how you get a fabric supported by a distribution kernel rather than a vendor tree.
Does this matter if I am not running a GPU pod?
Not directly, and most people never will run one. It matters as a signal about where accelerator interconnect is heading, because the open alternative to a proprietary scale up fabric only becomes real when the kernel support exists and ships in distributions. If you plan capacity for AI training or large scale inference, the presence or absence of an open scale up option changes your supplier options in a way that benchmark numbers do not. If you work on kernel memory management, the remote invalidation design is worth reading on its own merits.