From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34C16C021B5 for ; Sun, 23 Feb 2025 00:19:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9944F6B0083; Sat, 22 Feb 2025 19:19:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9443D6B0085; Sat, 22 Feb 2025 19:19:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 832936B0088; Sat, 22 Feb 2025 19:19:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 668E56B0083 for ; Sat, 22 Feb 2025 19:19:50 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B4A24A41C2 for ; Sun, 23 Feb 2025 00:19:49 +0000 (UTC) X-FDA: 83149301298.02.904E5E5 Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com [95.215.58.181]) by imf26.hostedemail.com (Postfix) with ESMTP id CF436140003 for ; Sun, 23 Feb 2025 00:19:47 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=bCAlKTiO; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740269988; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=jlL2mb66tqt9VKll+fCmLoFBo/AMjLtJs7I7sdBGVFE=; b=fdHXr4ngtQPRkdabGR7+DfynLxltkha5hBBzWpB1EACOMEpE4Y2re20t+3+yOtj4Jtj7bw xpWtfcTR7yIakHzokRo32HZpoO35dbjno8RMNV6RDbT3hYfSHQBlRMUk+PwHA56vA01LDb tFJWOA+SzcNOTlSL6NIrwJafuVCoIng= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=bCAlKTiO; spf=pass (imf26.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740269988; a=rsa-sha256; cv=none; b=xRayzwwTNdX1uIrTYgeF1weQxMbvqNsyxts7iidaumPR9l4tl2WU3Zeiph+Kpet6BzzhGz 1I1/H9uu7ugWOVefCfZPeEY1uNX9tHYSI/vPs5NOneH8FSeay9wvaurX0dy7uwO6ImcFuZ k/RVaa7WX3SMMmctH7eo53uKTX8Ppyg= Date: Sat, 22 Feb 2025 19:19:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1740269985; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=jlL2mb66tqt9VKll+fCmLoFBo/AMjLtJs7I7sdBGVFE=; b=bCAlKTiOsll53nHxgYXw1Hxh6MUAI6jL+TqWD0CaOcCYOl69d8KDcQs1lvFpc4ex5f79T8 IdcoIVXNJK/jTptXsuYwyiQkeX9AR7OtOot6t4UW27NWM5FdqYglg2qFDNkqU0N9hdoL27 B8tfPWryWXwiJGvevR7ZSnOzkav3SEA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Vlastimil Babka Cc: Suren Baghdasaryan , "Liam R. Howlett" , Christoph Lameter , David Rientjes , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Uladzislau Rezki , linux-mm@kvack.org, linux-kernel@vger.kernel.org, rcu@vger.kernel.org, maple-tree@lists.infradead.org, Sebastian Andrzej Siewior , Alexei Starovoitov Subject: Re: [PATCH RFC v2 00/10] SLUB percpu sheaves Message-ID: References: <20250214-slub-percpu-caches-v2-0-88592ee0966a@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250214-slub-percpu-caches-v2-0-88592ee0966a@suse.cz> X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: CF436140003 X-Stat-Signature: 73tubxnggyhbj9kimwg3f43axztjq96c X-HE-Tag: 1740269987-505823 X-HE-Meta: U2FsdGVkX18BrrEWe+ERnPLVk3Q0JgQbpKRUs0l528lxDWJOV35RGCT7RTAJFGEx4qfBM0cHnWViByyoZHSMmTqF1ACihdevPBLgDur2Zl9JKWZm29XGNMniqnpc9QTDFG1JkuUjT9cYVCl0BBf+H5GA30FvPtCB5zQ3uj9REHIwqByq3GlvgqT5gzPYzFHpfKatJoD2Jg78GhNAUTdfw8FVurc0ij4+bhb5hgz9SyWphDLcjNmfKzPY9iJ5nDMef+p+imSZ74kLcJMpChOGcs6SIV/rFSvM2hcbRJ+SMTDHSDshdMCwHZfB4l12pj7xsfThoihph/Eh9Sjd7M9ajMB4Pn/pEAu6UCGwGp5Psqfq83+GrAhX1bkGfKMUFA21YwkljNyByyWlVHjXPIO/yhMGm/qz8FX3Ipf4RncAIMja8v12kmmuy/aitxJ0+PO8UpX3MkuFVt7LTY9XMPTP8A99O5lcvMXZNDukkI9bUF2L/ligPzT4XpJunfTc28VFajxH52usNq2hhuyMWpJiLUcsRNGKttAraNoogiOvJsLuCX3yWOmIeu9ApjdjWJBYZ3DdDX7rotNV8kH+SYIHJiKuhPTtA5R6uuQx9HE08LIZ/dL7pyspZTmpRA48GKPlzs6UTXCjDt3TwwjguND1MJB3dsYlBKm0Syr6MdA0aSG70szma2DCNQBteQWOtYFMTD6czDHNVTYOs6x7n0tnjnGXCfFaEfvTex/9yQEACrECiJZcgr/DNseiX7tLRjb/z05gcWhT3e4D46jVe38qkbe39lhjaqqefYreLfzujohXoKEGllBKgku3c+fZYvMffcP42ziVtQxF8X2cBVZWz4xlQwfbO4GKDJNMAqdDOgKIO3fgIwEJnPEFTmmXbjgaUk83Pcm9NXGniF1S/S7qjNBkEEIzRLOZm9TWDg9+/1Af8lFQ8iEpe4PxUeB9L23QQTPgaiZOz/qTt/YCw6C hC5/DONi uweOnunsidfZTMw5FRs92O8npACP6iYlJb8tjynxo0ria2NufTPaMIvWrUTnvANaiZC755UThpXMXx/bSY7tjE1sJ5fgmKrFdZvgyUNUEuATCsOg2ZdcRc9rydWR6GKH+aHvYpgMHISa1o+i9Bx/GBFmsv9jCGOqbiK1gKkGWpkekP97mJrUs+X1m1psct5tPzE5xPStUYYG6xIFfr/1bY3QQxqVYhJtQH5GSEm7aDKPwYETLKnVKLgwdXyZJzx4rUkv9 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Feb 14, 2025 at 05:27:36PM +0100, Vlastimil Babka wrote: > - Cheaper fast paths. For allocations, instead of local double cmpxchg, > after Patch 5 it's preempt_disable() and no atomic operations. Same for > freeing, which is normally a local double cmpxchg only for a short > term allocations (so the same slab is still active on the same cpu when > freeing the object) and a more costly locked double cmpxchg otherwise. > The downside is the lack of NUMA locality guarantees for the allocated > objects. Is that really cheaper than a local non locked double cmpxchg? Especially if you now have to use pushf/popf... > - kfree_rcu() batching and recycling. kfree_rcu() will put objects to a > separate percpu sheaf and only submit the whole sheaf to call_rcu() > when full. After the grace period, the sheaf can be used for > allocations, which is more efficient than freeing and reallocating > individual slab objects (even with the batching done by kfree_rcu() > implementation itself). In case only some cpus are allowed to handle rcu > callbacks, the sheaf can still be made available to other cpus on the > same node via the shared barn. The maple_node cache uses kfree_rcu() and > thus can benefit from this. Have you looked at fs/bcachefs/rcu_pending.c?