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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7F2A3FD374E for ; Wed, 25 Feb 2026 13:22:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E2E86B0005; Wed, 25 Feb 2026 08:22:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 966A46B0088; Wed, 25 Feb 2026 08:22:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8721F6B008A; Wed, 25 Feb 2026 08:22:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7253A6B0005 for ; Wed, 25 Feb 2026 08:22:55 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id E9BE113B35D for ; Wed, 25 Feb 2026 13:22:54 +0000 (UTC) X-FDA: 84483044268.01.172A8E4 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf15.hostedemail.com (Postfix) with ESMTP id E6E14A0011 for ; Wed, 25 Feb 2026 13:22:52 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oAOi4prY; spf=pass (imf15.hostedemail.com: domain of vbabka@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=vbabka@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1772025773; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=KQVIfOU0aomW1O6CTNFUv1H8TudXDduXYh1xZsuypsQ=; b=AlyldM5YrtoaUDXO+Prdw88LLvt9eTGge/KdLMwtk25ehGC8DCGqXiLWYqa9mEdHHqRGwB T/KjcP/Z4Um/PTfETGjd03ss5xbuHYIa/7aYUa/7mv/RC2RCwJ/VW+PQqex6ZpwbpBf8bv lgcQSUcfcxXWGbf+Mgh8VUJrOzUF+WI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1772025773; a=rsa-sha256; cv=none; b=ecAqOH8l46MH6I3jGTuqtgGgFSu3bYBfZChgBqewahDeWrQ17j9BmlrNDwjtBz7dfV98Hv zUAr4gcNjYihaZWueDZ8FlXc/h2sY7bVHnBUCHbDRAh3/D/Dnry+Jk6ocOb47zHKNIyW8x 3+IAGWdvehmx3+xgJ9dTSI1xRgxreas= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oAOi4prY; spf=pass (imf15.hostedemail.com: domain of vbabka@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=vbabka@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id E66514444E; Wed, 25 Feb 2026 13:22:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A45BC116D0; Wed, 25 Feb 2026 13:22:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772025771; bh=RZBsUf0X02o3bPMs3VTOdahnvXKTjjrWfCtDKcZKalg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=oAOi4prYTzY0Ql6MaV7exYfYmjbmobHpo3I+e4JwPKf3lrttu5b/es42Zie+xxfu6 1ekF39MXArTWtm2iyfk7U3LDuMSW2tO7qEWKnYHOCxH/ta1+faUl/V0ZjKZoKuQiTm ThHyTyi6XE/wwfBlbtPQDv4Z7E1SoN0RHtq2B9hecciys5ZNxY293Q9NqCCzy/MAum ZWaGTVbna6IlKmzcLYm+GmMPWLd+Z3njTvZHQA034x5skL5xhLFZsINLcICHvGKoFv IDuP8WPhSRCp6xjb0tX41+BFoo8ehpYamIqejHkM4waigd/6geL3Ssucrzc9iheSab xF7kEIr4W60ZA== Message-ID: Date: Wed, 25 Feb 2026 14:22:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Regression] mm:slab/sheaves: severe performance regression in cross-CPU slab allocation Content-Language: en-US To: Ming Lei Cc: Vlastimil Babka , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, Harry Yoo , Hao Li , Christoph Hellwig References: <5cf75a95-4bb9-48e5-af94-ef8ec02dcd4d@suse.cz> <724310c2-46a2-4410-8a5d-c69dcc8de35d@kernel.org> From: "Vlastimil Babka (SUSE)" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E6E14A0011 X-Stat-Signature: 1h1qw1q1wbqbe69oi5ap4ey5yqdzhmsq X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1772025772-105310 X-HE-Meta: U2FsdGVkX1/if9RMMB5Xpb6NOAVslhIyEFl2QPMpkUjgdH0ESuc1RaZMdsX1p19pd/cuJZL2dJe/aIzI5ZtyJnoaE6vOGNC8h+TkBqKsudjSOJ1DWfJ6erQHb0lqrh5wacMVookmecnKGVGH4ZEVQqtueeKbrKjA5BaVm+FAgLOX/29/TtDvJq+QrcYX5MglfeYtOqy6QLxeHHzEusMh4hnIa04Hy05yLTthrlsUkVxl0KsdXnEeQjtqKzgakK7A9ospQqJWI9JlZFlcDjWl3vhFebYTcdoEyDlw84sT6h1QLzj34ALv3NwYxcOLFzbC+/KtDKalhqOSeMrFYRyUGyjYmDz/Lf8c4wokNuJ9duaebhraKxqaO19ZjIDUiv24gdxsXK5BDMp6hHyRwySCETYreYA27DorHh413ibyoLMgJMDLJqVMxFJPyAQ67wPR2G7gRBKpKjvApjGtP1xnL/T349oZQ7rf8EIjSsauYd4h+N6HMGbB7tvnFkHKx+4LftO7iZTnnxdQx8dPc9w2IVhXwetOTHt05bvtsIKlkwVL1LiLVZAK272j7TrrHqMglWoKTWtJFUfkbda4uli4btcMK7KKfjm6Bn17AgnTP7PMePpViSZy7CEsjidcUSft3MczkehUB7G/28muM5fuv2JOp3EMUJFmqjYkqeXuijQs+XzFraSxMqjQJgQ2pQ+2o0ojXIAW1TfZIvajy7CFA+QExQj5JDloPtOZFYMfDuTBfiwPaGSUa+bYjyUxCaQaun5nQbNxZG6ZUr5OUb1R/uc8XpNP3gMvVrZefTbiGmOP3MmDEUpuyCg9LJ6EiW0ElWJbNhjNUdsDVFpfx+66FAb9i1hxJPaKSJjUmgEofwvhAYZ41YTlIRrQI4UMii+baxWQMQjaPW1pRdmLTVqgWiQLrHzyGlVJcW+yi+c+cQSWPeyivo91GkcvdCmO9F0E81Ouf3rJPdy91C/oHCg FFovgF0Z TqKO+tpT9yb1f6LXb4VLIrgPTANsjL0wCJjc4s/Iutb1gqk7d9XJhpiwW1AI4phuLHJ5wub3qnQ3/b2/wPVR6TLuCxq2n4Pw+UXI72YKOcG03Jkk4dOuqNi33HVy5jXrb3Z69qzvS0+czSrVGLvr0NsGRa/Ey7mX1xs5IX7w1nfoc84T52MBhZdqiqpF1T4ZxFFN5fbUWQrdyezJhnvpJWTz/3Au2AUiZGCWW Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2/25/26 13:24, Ming Lei wrote: > On Wed, Feb 25, 2026 at 12:29:26PM +0100, Vlastimil Babka (SUSE) wrote: >> On 2/25/26 10:31, Ming Lei wrote: >> > Hi Vlastimil, >> > >> > On Wed, Feb 25, 2026 at 09:45:03AM +0100, Vlastimil Babka (SUSE) wrote: >> >> On 2/24/26 21:27, Vlastimil Babka wrote: >> >> > >> >> > It made sense to me not to refill sheaves when we can't reclaim, but I >> >> > didn't anticipate this interaction with mempools. We could change them >> >> > but there might be others using a similar pattern. Maybe it would be for >> >> > the best to just drop that heuristic from __pcs_replace_empty_main() >> >> > (but carefully as some deadlock avoidance depends on it, we might need >> >> > to e.g. replace it with gfpflags_allow_spinning()). I'll send a patch >> >> > tomorrow to test this theory, unless someone beats me to it (feel free to). >> >> Could you try this then, please? Thanks! >> > >> > Thanks for working on this issue! >> > >> > Unfortunately the patch doesn't make a difference on IOPS in the perf test, >> > follows the collected perf profile on linus tree(basically 7.0-rc1 with your patch): >> >> Hm that's weird, still the slowpath is prominent in your profile. >> >> I followed your reproducer instructions, although only with a small >> virtme-ng based setup. What's the output of "numactl -H" on yours, btw? > > available: 8 nodes (0-7) > node 0 cpus: 0 1 2 3 32 33 34 35 > node 0 size: 0 MB > node 0 free: 0 MB > node 1 cpus: 4 5 6 7 36 37 38 39 > node 1 size: 31906 MB > node 1 free: 30572 MB > node 2 cpus: 8 9 10 11 40 41 42 43 > node 2 size: 0 MB > node 2 free: 0 MB > node 3 cpus: 12 13 14 15 44 45 46 47 > node 3 size: 0 MB > node 3 free: 0 MB > node 4 cpus: 16 17 18 19 48 49 50 51 > node 4 size: 0 MB > node 4 free: 0 MB > node 5 cpus: 20 21 22 23 52 53 54 55 > node 5 size: 32135 MB > node 5 free: 31086 MB > node 6 cpus: 24 25 26 27 56 57 58 59 > node 6 size: 0 MB > node 6 free: 0 MB > node 7 cpus: 28 29 30 31 60 61 62 63 > node 7 size: 0 MB > node 7 free: 0 MB > node distances: > node 0 1 2 3 4 5 6 7 > 0: 10 12 12 12 32 32 32 32 > 1: 12 10 12 12 32 32 32 32 > 2: 12 12 10 12 32 32 32 32 > 3: 12 12 12 10 32 32 32 32 > 4: 32 32 32 32 10 12 12 12 > 5: 32 32 32 32 12 10 12 12 > 6: 32 32 32 32 12 12 10 12 > 7: 32 32 32 32 12 12 12 10 Oh right, memory-less nodes, of course. Always so much fun. >> >> Anyway what I saw is my patch raised the IOPS substantially, and with >> CONFIG_SLUB_STATS=y enabled I could see that >> /sys/kernel/slab/bio-248/alloc_slowpath had substantial values before the >> patch and zero afterwards. >> >> Maybe if you could also enable CONFIG_SLUB_STATS=y and see in which cache(s) >> there's significant alloc_slowpath even after the patch, it could help. > > Patched: > > /sys/kernel/slab/bio-264 > ./alloc_slowpath:83555260 C0=33 C1=6717992 C2=9 C3=6611030 C8=128 C9=6802316 C11=6934363 C13=6721479 C14=66 C15=6694472 C16=96 C17=7286868 C18=128 C19=7369091 C24=128 C25=7288673 C26=51 C27=6800502 C28=129 C29=7095073 C31=7232628 C43=4 C56=1 Yean, no slowpath allocations from cpus that are *not* on a memoryless node. Thanks, that will help to focus what to look at. > > Also config.tar.gz is attached. > > Thanks, > Ming