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.
