linux-kernel - Re: [tip:timers/core] [posix] 1535cb8028: stress-ng.epoll.ops_per

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANn89iKjCgmxtiLeVAiXODHbbR7=gYYi5cfAS1hS5qn+z=-o1Q@mail.gmail.com>
Date: Thu, 27 Mar 2025 07:21:10 +0100
From: Eric Dumazet <edumazet@...gle.com>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, kernel test robot <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev, 
	lkp@...el.com, linux-kernel@...r.kernel.org, x86@...nel.org, 
	Benjamin Segall <bsegall@...gle.com>, Frederic Weisbecker <frederic@...nel.org>
Subject: Re: [tip:timers/core] [posix] 1535cb8028: stress-ng.epoll.ops_per_sec
 36.2% regression

On Wed, Mar 26, 2025 at 10:11 PM Mateusz Guzik <mjguzik@...il.com> wrote:
>
> On Wed, Mar 26, 2025 at 09:07:51AM +0100, Thomas Gleixner wrote:
> > On Mon, Mar 24 2025 at 14:39, kernel test robot wrote:
> > > kernel test robot noticed a 36.2% regression of stress-ng.epoll.ops_per_sec on:
> > >
> > > commit: 1535cb80286e6fbc834f075039f85274538543c7 ("posix-timers: Improve hash table performance")
> > > https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git timers/core
> > >
> [snip]
> > > | testcase: change | stress-ng: stress-ng.epoll.ops_per_sec 124.9% improvement                       |
> >
> > How on earth can this commit result in both a 36% regression and a 25%
> > improvement with the same test?
> >
> > Unfortunately I can't reproduce any of it. I checked the epoll test
> > source and it uses a posix timer, but that commit makes the hash less
> > contended so there is zero explanation.
> >
>
> The short summary is:
> 1. your change is fine

Let me rephrase this.

Absolutely wonderful series, thanks a lot Thomas for doing it.

Next bottlenecks are now these ones, but showing up in synthetic
benchmarks only.


    33.36%  timer_storm      [kernel.kallsyms]           [k]
inc_rlimit_get_ucounts
            |
             --33.34%--inc_rlimit_get_ucounts
                       posixtimer_init_sigqueue
                       do_timer_create
                       __x64_sys_timer_create
                       do_syscall_64
                       entry_SYSCALL_64_after_hwframe
                       ___timer_create
                       0xe

    32.85%  timer_storm      [kernel.kallsyms]           [k]
dec_rlimit_put_ucounts
            |
             --32.83%--dec_rlimit_put_ucounts
                       posix_timer_unhash_and_free
                       __se_sys_timer_delete
                       do_syscall_64
                       entry_SYSCALL_64_after_hwframe
                       ___timer_delete

     9.61%  timer_storm      [kernel.kallsyms]           [k]
queued_spin_lock_slowpath
            |
            ---queued_spin_lock_slowpath
               |
               |--8.92%--_raw_spin_lock_irqsave
               |          |
               |           --8.91%--get_partial_node
               |                     ___slab_alloc
               |                     kmem_cache_alloc_noprof
               |                     do_timer_create
               |                     __x64_sys_timer_create
               |                     do_syscall_64
               |                     entry_SYSCALL_64_after_hwframe
               |                     ___timer_create
               |                     0xe
               |