RAM lasts a decade but servers don't, so Meta built a chip to keep DDR4 alive in DDR5 machines

Published Jul 30, 2026, 7:00 PM EDT I’m Adam Conway, an Irish technology fanatic with a BSc in Computer Science and I'm XDA’s Lead Technical Editor. My Bachelor’s thesis was conducted on the viability of benchmarking the non-functional elements of Android apps and smartphones such as performance, and I’ve been working in the tech industry in some way or another since 2017. In my spare time, you’ll probably find me playing Counter-Strike or VALORANT, and you can reach out to me at adam@xda-developers.com, on Twitter as @AdamConwayIE, on Instagram as AdamConwayIE, or u/AdamConwayIE on Reddit. Sign in to your XDA account Memory has become genuinely painful to buy over the last year, to the point that a DDR5 kit costs several times what the same capacity went for in 2024. That does odd things to how people think about the RAM they already own, and holding onto a platform you'd fully intended to replace starts looking less like stubbornness and more like basic math. Meta has a version of the same problem, except the math scales across millions of servers, and has been experiencing it for a lot longer than most. A paper its engineers presented at ISCA in late June describes Vistara, a custom Compute Express Link (CXL) chip that lets the company pull DDR4 out of decommissioned machines and reuse it in brand-new DDR5-based servers. To be clear about the timing, the paper never mentions memory prices at all, and the argument it makes is a good deal older than the current spike; Meta's reasons are capacity, carbon, and the fact that it was binning working DIMMs by the pallet. Having a way to recover another quarter of a terabyte per server without buying any has turned out to be remarkably good timing, mind, given what memory has done to everyone else's budgets since. It works, and it's running in production across caching, data warehouse, machine learning, and developer infrastructure workloads. The expanded tier also delivers about one-tenth the bandwidth of the DDR5 sitting beside it, workloads that can't cope with the latency simply get kept on local DRAM, and there's no version of this you could realistically use in a desktop. It's still the most interesting piece of memory engineering I've read about this year. Servers get retired years before their memory does Ten to fourteen years, versus five to seven Servers come out of the fleet after five to seven years, but the DRAM inside them stays useful for ten to fourteen, so every decommissioning cycle produces a pile of DIMMs that are nowhere near dead. Meta reckons DRAM accounts for 69% of its per-component carbon emissions, which makes throwing away working modules expensive in a way that's hard to represent with dollar amounts. At the same time, the company is short of memory elsewhere. Some 43.7% of its general-purpose servers are what the paper calls memory-capacity bound, meaning they run out of RAM long before they run out of anything else. Once the memory is full, nothing new can be scheduled onto whatever cores are still free, because there's nothing left to allocate to it, and that capacity is stranded. On older hardware generations it came to 25% to 40% of the processor. All of this basically boils down to the fact that the processors were fine, but there was nothing left to give them to do. So Meta has a surplus of DDR4 in one hand and a memory shortfall in the other, and the obvious move, to just put the old DDR4 back into the memory channels of the new servers, doesn't work. Modern server processors like AMD's Turin only expose DDR5 on their directly attached memory channels, so the old modules have nowhere to go. Even on a platform that could take them, dropping slower mixed-vintage DIMMs into those channels drags the whole subsystem down to their speed, which is a poor trade when the local memory is doing the heavy lifting. Vistara keeps the old DDR4 out of the memory channels It works over PCIe instead Credit: Meta Vistara is a custom ASIC, a CXL 2.0/1.1 Type-3 memory expander, and its job is to sit between reclaimed DDR4 and a processor whose native memory channels only support DDR5. Each chip carries two independent 72-bit DDR4 channels capable of 3200 MT/s, a PCIe Gen5 x16 host interface, and three RISC-V cores. Those cores handle secure boot, firmware authentication, device initialisation, health telemetry and error injection rather than memory traffic; the actual data moves through dedicated CXL logic, a CXL-to-DDR bridge, and the DDR controllers and PHYs. Meta's MemServer platform puts two of these on expansion cards in dedicated rear-accessible chassis slots, each on its own PCIe Gen5 x8 link, with accesses interleaved across both devices at 256-byte granularity. Between them they carry eight reclaimed 32GB RDIMMs for 256GB of expanded capacity. The server's own memory is untouched at 768GB of DDR5-6400 across 12 channels, so the 256GB brings the total to 1TB rather than replacing anything. The processor is a single-socket AMD Turin part exposing 158 available cores and 316 threads, and if that core count looks strange, that's because it is. It's not an EPYC SKU you can buy, but a product of Meta's platform configuration. Credit: Meta Linux sees the expanded capacity as a CPU-less NUMA node, and Meta specifically declined to let the BIOS present it as ordinary system RAM, deferring instead to the kernel's CXL driver. That driver brings it online as ZONE_MOVABLE, which keeps page tables, slab caches and anything else non-migratable in local DRAM where it belongs, and ACPI's CEDT and HMAT tables tell the kernel what the node is and roughly how slow it is. Meta had to work with platform vendors to get those right, because errors here can stop the entire thing from working. From there, Transparent Page Placement and Transparent Memory Offloading do the sorting, promoting hot pages up to DDR5 and demoting cold ones to DDR4. This works because the memory genuinely is cold. Median idle times across Meta's workloads run from about 1.7 minutes on one web service to 28.3 minutes on ads, and at least 75% of pages sit untouched for more than four seconds across everything measured. Applications run largely unmodified, though the paper does outline how NUMA policies and allocation strategies needed refinement for the whole thing to work. That isn't the same as the software work being trivial, mind. Meta absorbed most of it into the platform rather than pushing it out to the applications. The reclaimed memory is much slower, deliberately And CXL is most of the reason Credit: Meta There's a pretty large gap when it comes to speed, and in the company's all-read testing, local memory managed 497GB/s against a mere 48GB/s for the CXL tier. As well, idle latency ran roughly 130ns versus 250ns, and at 60% bandwidth utilisation that became 234ns against 372ns. That's not really DDR4's fault, though. Meta outlines how approximately 150ns of the latency penalty comes from the expander datapath itself, the controller, PHY and bridge, and the bandwidth gap is mostly down to running the DDR4 at 2400 MT/s, which Meta chose for both power and compatibility reasons, given that it's designed to work with a reclaimed pool containing nine different DIMM component types. What you get for accepting all of that, though, is capacity at 0.13 times the cost per gigabyte of local DRAM and 0.7 times the power per gigabyte. Even then, there's still more to consider: two ASICs and eight DIMMs draw about 50W between them, and the chassis needs directed airflow from high-capacity fans across the modules to keep them stable, so this is closer to a memory subsystem than an add-in card. There's a ceiling to all of this, and Meta found it. The local DDR5 is 768GB of the server's 1TB, or three quarters of it, so for as long as less than 75% of a workload's footprint is actively in use, everything hot fits in fast memory and only cold pages ever reach the DDR4. Sweeping that proportion in a synthetic test shows a flat regime below 75%, where latency overhead stays within 2% and CXL bandwidth below 7GB/s. At 75% it starts to give, with CXL traffic jumping to 12.4GB/s and latency overhead reaching 4%, because the hot set no longer fits in local DRAM and pages start moving between tiers far more often. It degrades quickly from there, reaching a 22% latency penalty when the entire footprint is hot. The ratio matters too. At a three-to-one split of local to CXL memory (what Meta actually uses), there was no measurable regression against an all-local system of the same total capacity, and two-to-one held up as well. At one-to-one it broke: a web service lost 3% MIPS and 6% of its request rate, and a data preprocessing service dropped 12% MIPS and 19% throughput. Once you start pushing more of the working set onto the slower DDR4 memory, you eventually pay for it. Every MemServer is presented as a uniform 1TB system, and the expanded memory is on by default, but workloads that can't tolerate the latency get fenced to local DRAM through the cpuset.mems cgroup controller with no reboot or BIOS change involved. For everything that can tolerate it, the payoff is pretty substantial. One caching service grew its usable cache from 680GB to 890GB and pushed sustainable queries per second up by a third, with cached objects surviving five to ten minutes before eviction instead of roughly one, and another cut its average query processing time by 29%. The CI fleet fits a third more build jobs per server, developer VMs went up by the same proportion for 15% fewer machines overall, and the ML parameter servers behind Meta's recommendation models need 25% fewer boxes while serving 12% more traffic. A CXL memory card already exists, but not for your PC It wants RDIMMs too Credit: Source: Gigabyte Here's the funny thing: I'd assumed all of this was hypothetical, but it turns out you can actually buy it. Gigabyte's AI TOP CXL R5X4 is a PCIe 5.0 x16 card running CXL 2.0/1.1 with four DDR5 slots, up to 512GB, a Microchip PM8712 controller, a full-metal heatsink with an AIO fan on it and an 8-pin power connector. It's validated for two motherboards: Gigabyte's own TRX50 AI TOP and W790 AI TOP, and the company asks buyers to check with it before purchasing rather than assuming a board with the right chipset will just work. Note that the slots take RDIMMs, the same as Vistara, and it's built around industry-standard DDR4 registered modules pulled from servers, not an unbuffered kit in a gaming PC. You don't want either of these, and what you'd want instead is an adapter that gives your old DDR4 somewhere to live. A consumer version of a system like this would need different validation and, quite possibly, a different controller and board design to handle UDIMMs in general. The reason your Ryzen or Core chip can't use one isn't that its memory controller only understands DDR5, either. CXL memory bypasses the DDR channels entirely and reaches the processor through a CXL-capable host bridge over the PCIe PHYs before firmware and the OS map it into the physical address space. The problem, though, is that usable CXL memory is a property of the whole platform rather than a feature the CPU either has or doesn't. You need the right root port, the lane routing, firmware that enumerates the device, correct ACPI tables, an operating system with a CXL driver and tiering support, and a validated device at the other end. Meta had to patch the Linux kernel and chase down ACPI bugs with vendors to get there. And the company is already building its own servers. None of this is unique to CXL, mind. A $10 SODIMM-to-UDIMM adapter will allow you to put laptop DDR5 into a desktop board and boot, but the board will still clamp a DDR5-5600 module to 3200 because it doesn't recognise what it's looking at. Firmware decides what your memory is allowed to be, and that decision is made long before anything is plugged in. CXL comes to servers first Consumer roadmaps quietly lapsed No mainstream consumer desktop platform currently exposes usable CXL.mem support. AMD floated bringing it to Ryzen back in 2022 with a three-to-five-year window attached, and that window has now quietly gone by without a peep. In the meantime, though, it's gone headfirst into server silicon; CXL 4.0 was finalised in November 2025, and AMD's 6th Gen EPYC parts announced in July carry CXL 3.1 across 128 PCIe Gen 6 lanes per socket. Vistara implements CXL 2.0, and the specification has been revised several times since. Even the merchant hardware is hard to come by, with Micron's CZ120, Samsung's CMM-D and SK hynix's CMM-DDR5 modules all reported as allocated to hyperscalers under direct supply agreements. Meta built its own silicon partly because nothing on the market suited it anyway, since most CXL products bundle the DRAM onto the controller, which defeats the purpose when the goal is reusing DIMMs you already have. The barrier doesn't really exist because nobody would build this; it's that the buyers who exist today are hyperscalers, server OEMs, and AI workstation vendors, all of whom the industry is already targeting. No desktop workload needs (or even wants) hundreds of gigabytes of memory running at a tenth of the bandwidth of sticks in DIMM slots. Vistara makes sense for Meta because 44% of its fleet struggles with capacity when there's a warehouse of tested RDIMMs sitting there unused. On top of that, cutting a quarter of the server count for ML parameter serving comfortably covers the costs of an ASIC program. A setup like this would be fun to have, but realistically, it's not all too useful for most consumers. What most people want isn't a CXL card, it's for 32GB of DDR5 to go back down in price to what it once was a couple of years ago.