Diagnosing a Linux Performance Regression

#1

Post by program » Mon, Sep 29, 2025, 6:46 PM UTC

Diagnosing a Linux Performance Regression
automattic.com

Re: Diagnosing a Linux Performance Regression

#2

Post by leetrout » Mon, Sep 29, 2025, 9:12 PM UTC

(January 2025)

Not something recent in the kernel.

Re: Diagnosing a Linux Performance Regression

#3

Post by zdw » Mon, Sep 29, 2025, 9:32 PM UTC

I wonder if this is still a problem if nftables was used instead.

nftables has been in mainline linux since 3.13 over a decade ago, and has been in the default in distros for a while (Debian 10 had it as default 6 years ago), but K8s support for it has lagged far behind, with it just recently out of beta in 1.33, and still not the default.

Re: Diagnosing a Linux Performance Regression

#4

Post by emmelaich » Tue, Sep 30, 2025, 12:01 AM UTC

leetrout wrote: post #2

(January 2025) Not something recent in the kernel.

I suspect using more than two year old (or even older) kernel versions in production is pretty common.

Anyone have stats on this?

Re: Diagnosing a Linux Performance Regression

#5

Post by boguscoder » Tue, Sep 30, 2025, 2:55 AM UTC

It almost reads as a cliffhanger, the regression was caused by commit that seemed to be related to fixing synchronization issue , so I assume just plain revert wasn’t an option