From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 11A96264638 for ; Tue, 16 Dec 2025 17:09:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765904956; cv=none; b=TqFScqY5NRSch9LW5cou+f17K/jgcVrQhrFSSmye4TVNZEMUctXIz1TNnv7q1SYzE/3Kw5/UuQOx8fGs/d9DgE4kB6d4x50RsM0GSClC1X6s6XctfkDzd7ZzmOhohG2dVaGCkQrVRjKV3UG4qYI4FjYBEMFxYI3sewVAjB4vxWU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765904956; c=relaxed/simple; bh=S8giOXa+oneuaqnAdz+6zpK2HTbbqMJTM2U8B8DZrfk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TiR+v6T1rblDXBLoFA3DxXkJUj0wQ2d1bnvrHeCbDViqxYXUzlRVWsYpTmpCmo8rrpcIqgiEHKFU5HBGiQY03PFFVdX8fMoV3NCUksSK/n724wqtbVTPspDOsSNjSGbEG7kDJ5+okxhpkyGq6AnF7MJvVgPcRI+XPjz3q2ggwoY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bJouOwnF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bJouOwnF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A32F7C4CEF1; Tue, 16 Dec 2025 17:09:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765904955; bh=S8giOXa+oneuaqnAdz+6zpK2HTbbqMJTM2U8B8DZrfk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bJouOwnFdXpyD9Uqh/z5H9qoiIeQo59KWtl8PIQmkLF9cYDkJqad6LYPJ3+0kILfA NwitJJIHP5RXMB8p8qFFemb08U08un7I4Lu9Iw9PefOHp5O5HWsMiDbpaU6TSQlUBv fVijeQtukTwrvNY+rhWBbTcyvAHPmO5asIWxRRUtQppOUK4X7vsIwok6pqhEHkoMBF bieMcfMBvKUk1mIawERgxJofdafcGV0As65DxfSbSGsfXyDqLi4+7+k3cGxBCK+3Sp XuNQJUkmfypHZCVjr4Nrngz/jTpsoa/LtaqDEdNAbFXXjb885oP0aE2W6N7Z2qxZzU e2uhD1jqlE0eg== Date: Tue, 16 Dec 2025 10:09:15 -0700 From: Tycho Andersen To: Mateusz Guzik Cc: oleg@redhat.com, brauner@kernel.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, willy@infradead.org Subject: Re: [PATCH v3 2/2] pid: only take pidmap_lock once on alloc Message-ID: References: <20251206131955.780557-1-mjguzik@gmail.com> <20251206131955.780557-3-mjguzik@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20251206131955.780557-3-mjguzik@gmail.com> 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) > + * (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