linux-kernel - Re: [PATCH v3 2/2] pid: only take pidmap

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: <aUGSO68Am0VWVAuv@tycho.pizza>
Date: Tue, 16 Dec 2025 10:09:15 -0700
From: Tycho Andersen <tycho@...nel.org>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: oleg@...hat.com, brauner@...nel.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, linux-mm@...ck.org, willy@...radead.org
Subject: Re: [PATCH v3 2/2] pid: only take pidmap_lock once on alloc

Hi Mateusz,

On Sat, Dec 06, 2025 at 02:19:55PM +0100, Mateusz Guzik wrote:
> When spawning and killing threads in separate processes in parallel the
> primary bottleneck on the stock kernel is pidmap_lock, largely because
> of a back-to-back acquire in the common case. This aspect is fixed with
> the patch.
> 
> Performance improvement varies between reboots. When benchmarking with
> 20 processes creating and killing threads in a loop, the unpatched
> baseline hovers around 465k ops/s, while patched is anything between
> ~510k ops/s and ~560k depending on false-sharing (which I only minimally
> sanitized). So this is at least 10% if you are unlucky.

Thanks for the patch.

In a particularly pathological case I can get a substantial
improvement in kernel CPU time with this patch:

Before:   Time (mean ± σ):     53.007 s ±  0.148 s    [User: 430.891 s, System: 12406.459 s]
After :   Time (mean ± σ):     45.624 s ±  0.394 s    [User: 435.021 s, System: 7692.072 s]

across 10 different boots. Feel free to add

Tested-by: Tycho Andersen (AMD) <tycho@...nel.org>

> +			 * (the routine unfortunately returns void, so we have no idea if it got anywhere).

Is it worth changing the return type? The underlying function looks
like it knows whether the allocation was actually successful...

Tycho