Linux 7.2 Showing Some Unexpected & Nice Performance Gains On AMD EPYC Sorano

Written by Michael Larabel in Linux Kernel on 23 June 2026 at 12:22 PM EDT. 5 Comments

While the Linux 7.2 merge window doesn't wrap up until this weekend as the feature cut-off for new material, I have already begun some early benchmarks of the code currently staged for this next version of the Linux kernel. Linux 7.2 already was looking quite exciting with cache aware scheduling and other exciting new features while an unexpected surprise in my early testing this week was seeing some local network/socket performance improvements.

The first system I used for evaluating the early performance of the Linux 7.2 kernel was a server with the new AMD EPYC 8005 "Sorano" series, namely the flagship AMD EPYC 8635P 84 cores / 168 thread Zen 5 processor. Linux 7.2 is looking good on EPYC Sorano and I'll have a complete overview of the kernel's performance soon, along with benchmarks on other hardware, but the unexpected surprise for this initial article was finding the localhost network performance to be nicely improved.

AMD EPYC 8635P server

Again, stay tuned for more thorough Linux 7.2 benchmarks once the merge window is over while for today is a brief dive into some nice networking performance gains that caught me by surprise.

With comparing Linux 7.1 stable to Linux 7.2 Git as of 21 June, it was a pleasant surprise seeing some unexpected improvements when testing the localhost performance of this EPYC Sorano server using xfr, the modern Rust-based alternative to iperf3:

xfr benchmark with settings of Server Address: localhost, Protocol: TCP, Threads: 1. Linux 7.2 Git 21 June was the fastest.

xfr benchmark with settings of Server Address: localhost, Protocol: TCP, Threads: 4. Linux 7.2 Git 21 June was the fastest.

xfr benchmark with settings of Server Address: localhost, Protocol: TCP, Threads: 16. Linux 7.2 Git 21 June was the fastest.

xfr benchmark with settings of Server Address: localhost, Protocol: TCP, Threads: 32. Linux 7.2 Git 21 June was the fastest.

The TCP performance was improved very nicely. The UDP performance was unchanged over Linux 7.1.

xfr benchmark with settings of Server Address: localhost, Protocol: QUIC, Threads: 1. Linux 7.2 Git 21 June was the fastest.

xfr benchmark with settings of Server Address: localhost, Protocol: QUIC, Threads: 2. Linux 7.2 Git 21 June was the fastest.

xfr benchmark with settings of Server Address: localhost, Protocol: QUIC, Threads: 4. Linux 7.2 Git 21 June was the fastest.

xfr benchmark with settings of Server Address: localhost, Protocol: QUIC, Threads: 8. Linux 7.2 Git 21 June was the fastest.

xfr benchmark with settings of Server Address: localhost, Protocol: QUIC, Threads: 16. Linux 7.2 Git 21 June was the fastest.

xfr benchmark with settings of Server Address: localhost, Protocol: QUIC, Threads: 32. Linux 7.2 Git 21 June was the fastest.

The xfr QUIC test was also showing nice improvements when running on the Linux 7.2 development kernel compared to Linux 7.1 stable. This is great news especially with AMD EPYC 8005 "Sorano" catering to telco, edge computing, cloud storage, and similar environments. It will be interesting to see in the upcoming tests if these improvements carry over similarly on other hardware too.

Sockperf benchmark with settings of Test: Latency Under Load. Linux 7.2 Git 21 June was the fastest.

Outside of xfr, the Sockperf network socket benchmark was showing lower latency too with Linux 7.2.

Stress-NG benchmark with settings of Test: Poll. Linux 7.2 Git 21 June was the fastest.

As a possible explanation for these unexpected improvements in Linux 7.2, when it came to running the stress-ng kernel micro-benchmarks it outed a possible explanation. The poll performance is multiple times faster on Linux 7.2 Git than Linux 7.1 stable.

When going through fs/select.c where poll is implemented within the kernel, for Linux 7.2 there is the adaptation of switching the poll code from free_page() to using the kmalloc() API. That change didn't notice any performance numbers but did indicate using the kmalloc API would provide better scalability, which is potentially what we are seeing here in these benchmarks. This is a generic improvement and nothing AMD or EPYC specific, so we should see gains on other hardware as well.

CPU Power Consumption Monitoring Overview benchmark with settings of Accumulated CPU Power Consumption Monitoring.

Also importantly was finding the AMD EPYC 8635P CPU power consumption not any higher on Linux 7.2 with these benchmark wins but in fact slightly lower than Linux 7.1.

In any event, stay tuned for more Linux 7.2 kernel benchmarks once the merge window is over and for now this was the first unexpected surprise so far this week in trying out the new AMD EPYC Sorano on this in-development Linux kernel.

5 Comments