Re: strange case of kernel performance regression (4.3.x and newer)

On Wed, Oct 5, 2016 at 8:18 AM, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
> Over the past couple of days I've been doing a bit of benchmarking for the
> "group clog" patch [1], and I've ran into what I suspect might be a fairly
> serious performance regression on newer kernels (essentially 4.3.0 and
> newer). I got to a point where I need help with further investigation,
> testing on other systems etc.
>
> The workload tested in the patch [1] is quite simple - a transaction with 3
> x SELECT FOR UPDATE queries and 2 x SAVEPOINT on unlogged tables. The
> results (average tps from 5 x 5 minute runs, for 32 and 64 clients) on
> multiple kernels look like this:
>
> kernel 32 64
> ---------------------------------
> 3.19.8 48524 59291
> 4.1.33 47193 59574
> 4.2.8 48901 59877
> 4.3.0 32187 38970
> 4.3.6 31889 38815
> 4.4.0 31946 37702
> 4.4.23 31498 37724
> 4.5.5 31531 37351
> 4.7.6 32859 38490

Just stumbled upon this old thread.

Since the regression is very clear and reproduceable and on a vanilla
kernel I don't think you need more testing. The kernel devs or at
least Linus take regressions (including performance) very seriously,
even if it's theoretically not the kernel's fault (so in this case
regardless what Postgres is doing).

I think you should just report it to lkml. If you have time to do a
bisection between 4.2.8 and 4.3.0 and find the offending commit that
would be even better, then email the author and CC lkml and Linus,
that should be enough to get it fixed.