From nobody Mon Feb 9 19:09:30 2026 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78D66371040 for ; Thu, 29 Jan 2026 09:08:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.130 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769677692; cv=none; b=ZdLRVItcuyLzZzIMuZQ/ouwdDDHQQRUUBFcgAKDUZ2TM/BQ4msyXF8xwtVdYymhtgid26hijSCbaXWaRfwvAzy3Wj3DGovSyBXzhLIxUp9bYnxV2mKi0zoi2/6/a+LEaX9s7nA8PKEMSKO4p/6t//Tf0SWm+aGTHse8rJ3TsTNM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769677692; c=relaxed/simple; bh=zmpKCilcQbXL+ot7k1JLUEd55SrQAzLCYoOUemDwyQQ=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=TQYW2BpfiecVrzQ8A7WtteVS4vSgnTodraUsqlBbaD5xxIn4frrsawlnUfyU0gIuC0ECdqSr1QuHFZ1LBXQ+rfUen9SnVAOgQlU5vY+1+E4hgO1P9aRnzz8euMCan5JmYxkq+CvC6vI3Ey9fYrrH+HYCk0/C+4pB6URabBPd8Vo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz; spf=pass smtp.mailfrom=suse.cz; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=CuwIF6Ej; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=3Nd/Tchb; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b=CuwIF6Ej; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b=3Nd/Tchb; arc=none smtp.client-ip=195.135.223.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.cz Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="CuwIF6Ej"; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="3Nd/Tchb"; dkim=pass (1024-bit key) header.d=suse.cz header.i=@suse.cz header.b="CuwIF6Ej"; dkim=permerror (0-bit key) header.d=suse.cz header.i=@suse.cz header.b="3Nd/Tchb" Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id F3A533405B; Thu, 29 Jan 2026 09:08:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1769677688; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=s0Uj5CtLWt5iohkdKRxxM31BtoyfocYHB/bXTO1htHU=; b=CuwIF6Ej5ONspel7vrMa5mVwl690lRZUnonRizeSx0WpTjEslBcdMU3qaSWUWdOarqOYuh CgHAGdKd3W+5B8VjmamTggMUSLNvNqQn0QLhqLMUkAZACSnaOsosNFFlUFxrNAGYDT+U41 mv3O5JegiqtauhP4szxQA3GULCJNBVc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1769677688; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=s0Uj5CtLWt5iohkdKRxxM31BtoyfocYHB/bXTO1htHU=; b=3Nd/TchbguN5/nmCiyArreevzl3xMJLSscwDUJSdmWbIjRQMUskZQwFjd/Xuh0OBtwlll5 yPioUsPqZ1o8GoCg== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1769677688; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=s0Uj5CtLWt5iohkdKRxxM31BtoyfocYHB/bXTO1htHU=; b=CuwIF6Ej5ONspel7vrMa5mVwl690lRZUnonRizeSx0WpTjEslBcdMU3qaSWUWdOarqOYuh CgHAGdKd3W+5B8VjmamTggMUSLNvNqQn0QLhqLMUkAZACSnaOsosNFFlUFxrNAGYDT+U41 mv3O5JegiqtauhP4szxQA3GULCJNBVc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1769677688; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=s0Uj5CtLWt5iohkdKRxxM31BtoyfocYHB/bXTO1htHU=; b=3Nd/TchbguN5/nmCiyArreevzl3xMJLSscwDUJSdmWbIjRQMUskZQwFjd/Xuh0OBtwlll5 yPioUsPqZ1o8GoCg== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D2D6E3EA61; Thu, 29 Jan 2026 09:08:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id XroeM3cje2l9CgAAD6G6ig (envelope-from ); Thu, 29 Jan 2026 09:08:07 +0000 From: Vlastimil Babka Date: Thu, 29 Jan 2026 10:07:57 +0100 Subject: [PATCH] slub: avoid list_lock contention from __refill_objects_any() 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-Transfer-Encoding: quoted-printable Message-Id: <20260129-b4-refill_any_trylock-v1-1-de7420b25840@suse.cz> X-B4-Tracking: v=1; b=H4sIAGwje2kC/x2M0QpAQBAAf0X77Op2SfErkg6LzXV0J5H8u+Nxa mZuCOyFA1TJDZ4PCbK6CJgm0M/GTaxkiAykqdBIpepy5XkUa1vjrnb3l137RWGhTYZEOZYZxHb 7nPP/1s3zvG3HmjxnAAAA X-Change-ID: 20260129-b4-refill_any_trylock-160a31224193 To: Harry Yoo , Hao Li Cc: Mateusz Guzik , Andrew Morton , Christoph Lameter , David Rientjes , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel test robot , Vlastimil Babka X-Mailer: b4 0.14.3 X-Developer-Signature: v=1; a=openpgp-sha256; l=3956; i=vbabka@suse.cz; h=from:subject:message-id; bh=zmpKCilcQbXL+ot7k1JLUEd55SrQAzLCYoOUemDwyQQ=; b=owGbwMvMwMG4+8GG0kuuHbMYT6slMWRWK5csZ/rupuZm9tB3/8w3vhP+P+0XKVCXde0o/RMg2 /FE2HlJJ6M/CwMjB4OlmCJL9e4TjqIzlT2mefh+hBnEygQyRVqkgQEIWBj4chPzSo10jPRMtQ31 DA11gEwGLk4BmOrmJPa/sn7LLNqv+UWnyT5dP3OdYqKeC2eTU9UvH45denP2JjJ9Plg9WaD7GVu 5r2XZVaaFdTutp9qb7d5ae+90mcgNvgaB/b8OPVII+dN0aEJNjpjgZa1Z6euWV31RDm/UdhYreB /9TudjVKDwgR/8Ub4ijo2tamtMl/hLfl8mJXb03qnr+nrLrrQxLozLyuWSfqvDuGzioaUfJ2c+W v+Z0fNh1yHj66s+S3Qyc/5x732Ve4U3bEri3PRLb3nyGFYtvHFk+VXWOt+1up+1al4aXImXOJIU ++V1+BPOGJHS05ER729e2RVcUHflwPc/CyyYAg+vq+nf0xBReqCRrVPvyryF0Wy21fcD5K9XOFq 87LgBAA== X-Developer-Key: i=vbabka@suse.cz; a=openpgp; fpr=A940D434992C2E8E99103D50224FA7E7CC82A664 X-Spam-Score: -4.30 X-Spamd-Result: default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_SEVEN(0.00)[11]; FUZZY_RATELIMITED(0.00)[rspamd.com]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; DKIM_SIGNED(0.00)[suse.cz:s=susede2_rsa,suse.cz:s=susede2_ed25519]; FROM_HAS_DN(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,linux-foundation.org,gentwo.org,google.com,linux.dev,kvack.org,vger.kernel.org,intel.com,suse.cz]; TO_DN_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; URIBL_BLOCKED(0.00)[imap1.dmz-prg2.suse.org:helo,intel.com:email,suse.cz:mid,suse.cz:email]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.cz:mid,suse.cz:email,intel.com:email] X-Spam-Level: X-Spam-Flag: NO Kernel test robot has reported a regression in the patch "slab: refill sheaves from all nodes". When taken in isolation like this, there is indeed a tradeoff - we prefer to use remote objects prior to allocating new local slabs. It is replicating a behavior that existed before sheaves for replenishing cpu (partial) slabs - now called get_from_any_partial() to allocate a single object. So the possibility of allocating remote objects is intended even if remote accesses are then slower. But the profiles in the report also suggested a contention on the list_lock spinlock. And that's something we can try to avoid without much tradeoff - if someone else has the spin_lock, it's more likely they are allocating from the node than freeing to it, so we can skip it even if it means allocating a new local slab - contributing to that lock's contention isn't worth it. It should not result in partial slabs accumulating on the remote node. Thus add an allow_spin parameter to __refill_objects_node() and get_partial_node_bulk() to make the attempts from __refill_objects_any() use only a trylock. Reported-by: kernel test robot Link: https://lore.kernel.org/oe-lkp/202601132136.77efd6d7-lkp@intel.com Signed-off-by: Vlastimil Babka Tested-by: Hao Li --- To be applied on top of: https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab.git/log/?h=3Dsl= ab/for-7.0/sheaves --- mm/slub.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index eb1f52a79999..ca3db3ae1afb 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3378,7 +3378,8 @@ static inline bool pfmemalloc_match(struct slab *slab= , gfp_t gfpflags); =20 static bool get_partial_node_bulk(struct kmem_cache *s, struct kmem_cache_node *n, - struct partial_bulk_context *pc) + struct partial_bulk_context *pc, + bool allow_spin) { struct slab *slab, *slab2; unsigned int total_free =3D 0; @@ -3390,7 +3391,10 @@ static bool get_partial_node_bulk(struct kmem_cache = *s, =20 INIT_LIST_HEAD(&pc->slabs); =20 - spin_lock_irqsave(&n->list_lock, flags); + if (allow_spin) + spin_lock_irqsave(&n->list_lock, flags); + else if (!spin_trylock_irqsave(&n->list_lock, flags)) + return false; =20 list_for_each_entry_safe(slab, slab2, &n->partial, slab_list) { struct freelist_counters flc; @@ -6544,7 +6548,8 @@ EXPORT_SYMBOL(kmem_cache_free_bulk); =20 static unsigned int __refill_objects_node(struct kmem_cache *s, void **p, gfp_t gfp, unsigned = int min, - unsigned int max, struct kmem_cache_node *n) + unsigned int max, struct kmem_cache_node *n, + bool allow_spin) { struct partial_bulk_context pc; struct slab *slab, *slab2; @@ -6556,7 +6561,7 @@ __refill_objects_node(struct kmem_cache *s, void **p,= gfp_t gfp, unsigned int mi pc.min_objects =3D min; pc.max_objects =3D max; =20 - if (!get_partial_node_bulk(s, n, &pc)) + if (!get_partial_node_bulk(s, n, &pc, allow_spin)) return 0; =20 list_for_each_entry_safe(slab, slab2, &pc.slabs, slab_list) { @@ -6650,7 +6655,8 @@ __refill_objects_any(struct kmem_cache *s, void **p, = gfp_t gfp, unsigned int min n->nr_partial <=3D s->min_partial) continue; =20 - r =3D __refill_objects_node(s, p, gfp, min, max, n); + r =3D __refill_objects_node(s, p, gfp, min, max, n, + /* allow_spin =3D */ false); refilled +=3D r; =20 if (r >=3D min) { @@ -6691,7 +6697,8 @@ refill_objects(struct kmem_cache *s, void **p, gfp_t = gfp, unsigned int min, return 0; =20 refilled =3D __refill_objects_node(s, p, gfp, min, max, - get_node(s, local_node)); + get_node(s, local_node), + /* allow_spin =3D */ true); if (refilled >=3D min) return refilled; =20 --- base-commit: 6f1912181ddfcf851a6670b4fa9c7dfdaf3ed46d change-id: 20260129-b4-refill_any_trylock-160a31224193 Best regards, --=20 Vlastimil Babka