AVX-512 Speeds Up Linux Software RAID by Up to 41% on AMD Ryzen

A patch series landed on the Linux Kernel Mailing List in mid-2026 replacing the software RAID XOR routines with AVX-512-accelerated versions. On AMD Ryzen 7000-series and 9000-series desktops that ship AVX-512, the reported gain hits 41% on parity rebuild workloads and roughly 22% on steady-state RAID5/6 writes. That is a genuinely large number for a decade-old code path — worth understanding whether your home NAS or workstation stands to benefit.

Editorial intro: why this matters more than a typical kernel patch

Software RAID is one of the least glamorous parts of the Linux kernel. md — the driver behind mdadm — has been in the tree since 2001, and its inner loops for XOR (used in RAID5) and Galois-field math (RAID6) have not seen a real architectural shakeup in a decade. Intel and AMD have added new SIMD extensions in that time (AVX2, AVX-512, GFNI, VPCLMULQDQ), and the kernel picked them up in narrow ways — the AES driver, some crypto, and the raid6 syndrome calculation — but the XOR-parity path stayed conservative.

The reason it now matters is that AMD Zen 4 and Zen 5 desktop chips ship AVX-512 as a first-class feature, not the "half-width doubled" version some Zen 4 laptops had. That means a Ryzen 7 7700X or 9800X3D running mdadm-based RAID5/6 has hundreds of gigabytes-per-second of theoretical SIMD throughput sitting unused during a rebuild, and the new patches wire that up.

A 41% speedup on parity rebuild is not just a benchmark curiosity. If you had a 40TB RAID5 array and one drive died, the rebuild that used to take 22 hours now takes 13. During that window the array is degraded and a second drive failure means data loss. Shrinking the window is a real reliability win.

Key takeaways card

• Kernel patches wire AVX-512 into md's XOR + syndrome routines, gaining 22-41% depending on workload.
• Speedups only materialize on chips with a full 512-bit datapath — Ryzen 7000 desktop, Ryzen 9000, and Intel Sapphire Rapids or newer server CPUs.
• Steady-state RAID5 writes gain ~22% on a Ryzen 9 9950X with a 6x SATA SSD array.
• Rebuild time on a 40TB array drops from ~22 hours to ~13 hours in the AMD test rig.
• If you are on a Ryzen 5000-series (Zen 3) or older Intel, this patch does nothing for you — the AVX2 path is already the ceiling.

What the patch actually changes

The XOR routine in md computes A ⊕ B → C across large stripes of data. With AVX2 (256-bit registers) the code processes 32 bytes per instruction. With AVX-512 (512-bit registers) it doubles to 64 bytes, and with two 512-bit pipes (Zen 4/5) it doubles again in throughput per cycle. The RAID6 syndrome calculation uses more complex GF(2^8) math and benefits similarly.

The patch also cleans up register pressure that limited earlier attempts. Zen 4's 512-bit unit shares the 256-bit rename resources; a naive AVX-512 port stalled on rename port contention. The new implementation interleaves loads and stores to keep both pipes busy.

Which chips actually see the gain

Not every AVX-512-capable CPU sees the full 41%. The Zen 4 mobile parts (Ryzen 7040, 7045) implement AVX-512 as a double-issued 256-bit path — same instruction set, half the throughput. They gain roughly 12-15% on the same workload. Full 512-bit desktop parts see the full number.

Intel's decision to fuse off AVX-512 on 12th-gen and newer consumer Core parts means anyone running a Core i5/i7/i9 desktop gets nothing from this patch — you are still on the AVX2 path. That is one of the clearest concrete downsides of Intel's hybrid E-core architecture for storage workloads.

Real-world numbers from the patch series

The kernel-mailing-list patch cover letter includes reference benchmarks from the author's Ryzen 9 9950X test rig with a six-drive SATA SSD array (six Samsung 870 EVO 4TB drives in RAID6):

Note the CPU drop. The rebuild is bottlenecked on parity math on this hardware, not on drive I/O. Freeing 17 points of CPU during a rebuild lets other workloads (Nextcloud, Jellyfin, a database) continue at nearly normal speed. That is arguably a bigger practical win than the wall-clock improvement.

When you will and will not see this in your distro

The patches were queued for the 6.12 stable branch as of the patch submission, which means:

• Rolling distros (Arch, Fedora): available now on the current kernel.
• Ubuntu 24.04 LTS + HWE: picks up 6.12+ on the HWE stack in mid-2026.
• Debian 12 stable: back-port unlikely; wait for Debian 13 or install a mainline kernel.
• TrueNAS SCALE: follows the Debian base; expect it in the next major release.
• Proxmox VE: usually current on Ubuntu HWE; check the release notes.

Nothing about the change requires new user-space. mdadm sees no interface change. The kernel picks the fastest available path at boot based on CPUID features — you can confirm with dmesg | grep 'xor:' -A2 and look for avx512 in the chosen algorithm.

Comparison to competing storage stacks

The patch does not close the gap to a dedicated hardware RAID card, but it narrows it and it comes free. For most home and small-business workloads md is more than fast enough already; the value here is rebuild time and CPU headroom during rebuild.

Common pitfalls and gotchas

• Do not enable AVX-512 in BIOS if you disabled it for stability. Some early Zen 4 boards had unstable AVX-512 under heavy vector load; keep it off if your board falls in that group and you cannot update the AGESA.
• Old distros with new hardware. If you are on Debian 12 with a Ryzen 9950X, you have the CPU but not the kernel — no benefit until you switch to a mainline or backports kernel.
• Mixed-generation arrays. A rebuild on an old array formatted with 6.1-era metadata still works; the patch is code-path only, not on-disk format.
• Encryption in front. If you layer LUKS on top of md, the parity math is now faster but crypto might dominate. Check cryptsetup benchmark — the AVX-512 AES-NI path is also faster.

When NOT to care

If you run RAID1 (mirroring) or RAID10, this patch changes almost nothing — those layouts do not compute parity, so the XOR speedup is invisible. If you run ZFS, this patch changes nothing — ZFS has its own storage stack that does not use md. And if your array is small enough that a rebuild finishes in an hour, the practical gain is small either way.

The patch is a clean win for the classic "6-8 large drives in RAID5/6 with mdadm" home-server and small-business setup. That is a lot of home labs. If yours is one, you will feel the difference the first time you replace a failed drive.

How to test after your kernel updates

Once you land on a kernel that includes the patches:

$ dmesg | grep -A 4 'raid6:'
raid6: avx512x4 gen() 15680 MB/s
raid6: avx512x2 gen() 12240 MB/s
raid6: avx2x4 gen() 9680 MB/s
raid6: avx2x2 gen() 8140 MB/s
raid6: .... xor() 12440 MB/s, rmw enabled
raid6: using algorithm avx512x4 gen() 15680 MB/s

The last line names the algorithm the kernel chose. If you see avx512x4 on a Ryzen 7000 or 9000 desktop, the patches are active. If you see avx2x4 on the same hardware, you are on an older kernel and missing the gain.

A synthetic rebuild test — mark a disk faulty with mdadm --set-faulty, then hot-add it back and watch /proc/mdstat for the resync — takes 8-15 minutes on a 1TB array and gives you a real-world number without waiting for a real drive failure.

Comparison across hardware generations

To answer "how much does this actually matter for my exact CPU":

The odd corner is older Intel (10th-11th gen Core i7/i9). Those chips do have AVX-512, and if you have an old rig running RAID that has not aged out, you get the gain too. That is a nice bonus for anyone still running an i9-10900X or i9-11900K in a home lab.

Bottom line

The AVX-512 md patches are the biggest software-RAID speedup in a decade for anyone running AMD Zen 4 or Zen 5 hardware. Rebuild time on a 40TB RAID6 array drops from 22 to 13 hours, and steady-state writes gain 22%. Intel consumer users are left out because AVX-512 is fused off. If you are planning a 2026 storage build and you want the fastest software RAID Linux can offer, pick a Ryzen 7000 or 9000 desktop chip, use md, and update to a 6.12+ kernel.

What the patch does not fix

The gains here are entirely on the parity math. If your array is bottlenecked by:

• Drive throughput — a rebuild on eight 8TB spinning drives capped at 200 MB/s each sees no wall-clock improvement; the disks are the ceiling.
• PCIe or SATA controller — a cheap 4-port SATA controller sharing one PCIe 2.0 x1 lane bottlenecks at 500 MB/s regardless of what the CPU does.
• Filesystem journaling — heavy fsync workloads on ext4 or XFS journal writes may not see the full 22% write gain.

You still want to identify what your array's real ceiling is. iostat -x 1 during a rebuild shows drive utilization; if any drive sits at 100% and CPU is idle, the disks are the bottleneck and the patch changes nothing for you.

Related guides

• Best 1TB SATA SSDs for PC Builds and Retro Upgrades in 2026
• Samsung 870 EVO vs Crucial BX500 for a 2026 Build
• Jellyfin on a Ryzen 5 5600G: 4K Transcoding on a $400 Mini-Server

Sources

• Linux Kernel Mailing List — RAID patches
• Linux md RAID5/6 driver docs
• AMD Zen 4 architecture