linux-kernel - Re: [linus:master] [pidfs] 16ecd47cb0: stress-ng.fstat.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] [day] [month] [year] [list]

Message-ID: <ea7fq465sidc3gonlqcd33s64tzjogdo2lhnye5tau22pbs4d5@426xzgsios3q>
Date: Tue, 28 Jan 2025 14:38:57 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Christian Brauner <brauner@...nel.org>
Cc: kernel test robot <oliver.sang@...el.com>, oe-lkp@...ts.linux.dev, 
	lkp@...el.com, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [linus:master] [pidfs]  16ecd47cb0:  stress-ng.fstat.ops_per_sec
 12.6% regression

On Tue, Jan 28, 2025 at 11:51:49AM +0100, Christian Brauner wrote:
> On Mon, Jan 27, 2025 at 10:32:11PM +0800, kernel test robot wrote:
> > 
> > 
> > Hello,
> > 
> > kernel test robot noticed a 12.6% regression of stress-ng.fstat.ops_per_sec on:
> 
> I'm confused about how this would affect stat performance given that it
> has absolutely nothing to do with stat. Is this stating pidfds at least?
> 
> 

stress-ng is issuing the "claimed" syscall in some capacity, but it also
mixes in other stuff.

In this particular case the test continuously creates and destroys
threads.

This in turn runs into pid alloc/dealloc code you modified.

I verified with bpftrace that contention around pid alloc *is seen*.

one-liner: bpftrace -e 'kprobe:__pv_queued_spin_lock_slowpath { @[kstack()] = count(); }'

@[
    __pv_queued_spin_lock_slowpath+5
    _raw_spin_lock_irqsave+49
    free_pid+44
    release_task+609
    do_exit+1717
    __x64_sys_exit+27
    x64_sys_call+4654
    do_syscall_64+82
    entry_SYSCALL_64_after_hwframe+118
]: 472350
@[
    __pv_queued_spin_lock_slowpath+5
    _raw_spin_lock_irq+42
    alloc_pid+390
    copy_process+6112
    kernel_clone+155
    __do_sys_clone3+194
    do_syscall_64+82
    entry_SYSCALL_64_after_hwframe+118
]: 568447

there is of course tons more

So the new code is plausibly slower to alloc/dealloc and is lowering
throughput as a result.

I'll note though that thread creation/destruction has pretty horrid
scalability as is.