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 80E21C28B28 for ; Mon, 17 Mar 2025 11:09:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6785B280002; Mon, 17 Mar 2025 07:09:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 625B3280001; Mon, 17 Mar 2025 07:09:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49FFF280002; Mon, 17 Mar 2025 07:09:00 -0400 (EDT) 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 2BC45280001 for ; Mon, 17 Mar 2025 07:09:00 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 20675121C71 for ; Mon, 17 Mar 2025 11:09:00 +0000 (UTC) X-FDA: 83230770840.25.1F8A457 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf26.hostedemail.com (Postfix) with ESMTP id E1578140002 for ; Mon, 17 Mar 2025 11:08:57 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=hwWjiKe4; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=B0T0sJOJ; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=hwWjiKe4; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=B0T0sJOJ; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742209738; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=t/DK9r72Uol6zgQzU2gC1hGvx4LoRdqfQlA9txMt/Pg=; b=z3jemjNMo0hp1gN4RclxYn/hiQJoONZTUc+SC9bTo5tpuR8F3+Tx+dbVLEHjHPzHqrMSRk X9BhqYzprHjyVGCDFlp/OoZM5wnxYb8/7SRp+EIKRVkkrumadTwFkdHgLVAAId445wbiO6 8CymZEA22q/ca7hdzU5fhYNNlSVCpUM= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=hwWjiKe4; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=B0T0sJOJ; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=hwWjiKe4; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=B0T0sJOJ; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742209738; a=rsa-sha256; cv=none; b=h7kJOz1/O5sNJrCl8M1S2/mQFg7BDvzH8kqLiiIuASYXyC9sTErTm+m7gZzbvION+Et+rM 1KQ1K2dL9uxytu/jcDpw0+G+BCmdi6gwIV7ZQYVjEh6WJxMPxK5PniDONPWNecQbxAs45J c+2pNOqww47QvrZIpFSyNe2v+9X4zJc= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104: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 1614B21C94; Mon, 17 Mar 2025 11:08:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1742209736; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=t/DK9r72Uol6zgQzU2gC1hGvx4LoRdqfQlA9txMt/Pg=; b=hwWjiKe4+VhV/uDqgYQCVtEp6iPqo//Gghh2Uclg9qsm7CAW8y0WUk79lIYOspdCGfXHZn Nu0S8yFRFhO4C+KgjopzH1DTSjODZdQQIMkGWvI02CogM/wqPNyRwXr8RyAyiVOhlN5Jeh qGoPQtIzNCueZaEocPQnQKesdqcwO5I= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1742209736; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=t/DK9r72Uol6zgQzU2gC1hGvx4LoRdqfQlA9txMt/Pg=; b=B0T0sJOJKeCFIJiQ4OJAT4s4s29ghj+674SrtqIOwEIIjprm/G+NqeTzcHYSdZBnIQYexW bOyFuPBtCepgkJCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1742209736; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=t/DK9r72Uol6zgQzU2gC1hGvx4LoRdqfQlA9txMt/Pg=; b=hwWjiKe4+VhV/uDqgYQCVtEp6iPqo//Gghh2Uclg9qsm7CAW8y0WUk79lIYOspdCGfXHZn Nu0S8yFRFhO4C+KgjopzH1DTSjODZdQQIMkGWvI02CogM/wqPNyRwXr8RyAyiVOhlN5Jeh qGoPQtIzNCueZaEocPQnQKesdqcwO5I= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1742209736; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=t/DK9r72Uol6zgQzU2gC1hGvx4LoRdqfQlA9txMt/Pg=; b=B0T0sJOJKeCFIJiQ4OJAT4s4s29ghj+674SrtqIOwEIIjprm/G+NqeTzcHYSdZBnIQYexW bOyFuPBtCepgkJCQ== 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 E85FA139D2; Mon, 17 Mar 2025 11:08:55 +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 e+QlOMcC2GfnLgAAD6G6ig (envelope-from ); Mon, 17 Mar 2025 11:08:55 +0000 Message-ID: Date: Mon, 17 Mar 2025 12:08:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC v2 00/10] SLUB percpu sheaves Content-Language: en-US To: Suren Baghdasaryan , "Liam R. Howlett" , Kent Overstreet , 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 , Sidhartha Kumar References: <20250214-slub-percpu-caches-v2-0-88592ee0966a@suse.cz> <173d4dbe-399d-4330-944c-9689588f18e8@suse.cz> <19df9218-c984-4cbc-8b5d-4e0f7658935f@suse.cz> From: Vlastimil Babka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Action: no action X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E1578140002 X-Stat-Signature: r8fjfeqjnwyoyhzywdwqpmf81crp56h7 X-HE-Tag: 1742209737-40400 X-HE-Meta: U2FsdGVkX19I9TmehRWXhZZC9jB6DU/SaWHsOgxu7kyOyHrEU7TKWo/YC+EQYwHhPry2IKb6cdHZP+eJtK9KYZF8T9nLpvdwp1Z3We3/UGI5Y8s+MocLl47qsa+DfNlMssFSz/Vy0HqFyD+/TG1kJG0ymvDAy3Mde51qQWPAaJR5q9mBPLmePqfsFKC8e/OUr6h6PEjjVW8n2Bz6ZViMW+suZ2YUWFBjrHgT4bopaKw2mv/WM9nPxfHNOvnnBZS6hvbvQW88LMDdy5D31ARBaQkYjo5VBA2gCm/zibhLUXz6OG3BfNayk5fi9zkbjqiDWd300vgc6p3n3iBpNlPMssfR7dbadls4H5Dr4uf9MrY4WmJy5T30ePHCsI1JX3LleGLFVCqSinv7fRLT5MAYTNuXlteyeTHhf1mHlbnrdQwiF9x0ZaJ8PxhdoxuGJoMIB+mvMYNZRILe0RFLbE19HxZOWUZfysPR129KdVVUmRuGgD6FRhfXQQG4AF1WJ6W8bwHkJWT3HrT0kCUlQgyHPEmVnRD9CsIB8pP7RLYCAhGG2GamhDqZ5R7w9f57YD2hnvA1INORxiMoMrnuA8UqNK25VG22R+KHchq9WSlgV3zFr4mSDmvJlRgB5J9RuqejuD3f8TyaiyYsTWc788TKYHHfHGoUqb0HzvVNR632oaslKRpCdEFT8YW3fXiu0GBiNOZA/kdU4lhftgcBSyVJ4JrOP8SZ5moAs59tcI+zasUCFw1q9ivJQIfoPFvfUd3EtB+8Km6C9nIBWBteqHn7wO1YJoGwsaZYV/EE7PfPrQHHw9yHN2lxnsJUSyskbiANbWB0KWXb28a8biWnAbSCQtFf1Jlj5bkjSR/PUdf7kPYLMVYA6MowLTT0hIOAbbr7wRAnrTN3rbyGxDdtDP1e/kJvjeQQeAUY5adZh5at4cYq2H2LXv8cNydcOhdWF6uvioSpkYJyKlLVAausnz2 v2tDRQI2 YqAbZJ4I6sjxaF/DU1810IZqmy85fDHK+94Uh 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 3/14/25 18:10, Suren Baghdasaryan wrote: > On Tue, Mar 4, 2025 at 11:08 AM Liam R. Howlett wrote: >> >> * Vlastimil Babka [250304 05:55]: >> > On 2/25/25 21:26, Suren Baghdasaryan wrote: >> > > On Mon, Feb 24, 2025 at 1:12 PM Suren Baghdasaryan wrote: >> > >> >> > >> > >> > >> > > The values represent the total time it took to perform mmap syscalls, less is >> > >> > > better. >> > >> > > >> > >> > > (1) baseline control >> > >> > > Little core 7.58327 6.614939 (-12.77%) >> > >> > > Medium core 2.125315 1.428702 (-32.78%) >> > >> > > Big core 0.514673 0.422948 (-17.82%) >> > >> > > >> > >> > > (2) baseline control >> > >> > > Little core 7.58327 5.141478 (-32.20%) >> > >> > > Medium core 2.125315 0.427692 (-79.88%) >> > >> > > Big core 0.514673 0.046642 (-90.94%) >> > >> > > >> > >> > > (3) baseline control >> > >> > > Little core 7.58327 4.779624 (-36.97%) >> > >> > > Medium core 2.125315 0.450368 (-78.81%) >> > >> > > Big core 0.514673 0.037776 (-92.66%) >> > > >> > > (4) baseline control >> > > Little core 7.58327 4.642977 (-38.77%) >> > > Medium core 2.125315 0.373692 (-82.42%) >> > > Big core 0.514673 0.043613 (-91.53%) >> > > >> > > I think the difference between (3) and (4) is noise. >> > > Thanks, >> > > Suren. >> > >> > Hi, as we discussed yesterday, it would be useful to set the baseline to >> > include everything before sheaves as that's already on the way to 6.15, so >> > we can see more clearly what sheaves do relative to that. So at this point >> > it's the vma lock conversion including TYPESAFE_BY_RCU (that's not undone, >> > thus like in scenario (4)), and benchmark the following: >> > >> > - baseline - vma locking conversion with TYPESAFE_BY_RCU >> > - baseline+maple tree node reduction from mm-unstable (Liam might point out >> > which patches?) >> >> Sid's patches [1] are already in mm-unstable. >> >> >> > - the above + this series + sheaves enabled for vm_area_struct cache >> > - the above + full maple node sheaves conversion [1] >> > - the above + the top-most patches from [1] that are optimizations with a >> > tradeoff (not clear win-win) so it would be good to know if they are useful >> > >> > [1] currently the 4 commits here: >> > https://web.git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slub-percpu-sheaves-v2-maple >> > from "maple_tree: Sheaf conversion" to "maple_tree: Clean up sheaf" >> > but as Liam noted, they won't cherry pick without conflict once maple tree >> > node reduction is backported, but he's working on a rebase >> >> Rebased maple tree sheaves, patches are here [2]. > > Hi Folks, > Sorry for the delay. I got the numbers last week but they looked a bit > weird, so I reran the test increasing the number of iterations to make > sure noise is not a factor. That took most of this week. Below are the > results. Please note that I had to backport the patchsets to 6.12 > because that's the closest stable Android kernel I can use. I measure > cumulative time to execute mmap syscalls, so the smaller the number > the better mmap performance is: Is that a particular benchmark doing those syscalls, or you time them within actual workloads? > baseline: 6.12 + vm_lock conversion and TYPESAFE_BY_RCU > config1: baseline + Sid's patches [1] > config2: sheaves RFC > config3: config1 + vm_area_struct with sheaves > config4: config2 + maple_tree Sheaf conversion [2] > config5: config3 + 2 last optimization patches from [3] > > config1 config2 config3 config4 config5 > Little core -0.10% -10.10% -12.89% -10.02% -13.64% > Mid core -21.05% -37.31% -44.97% -15.81% -22.15% > Big core -17.17% -34.41% -45.68% -11.39% -15.29% Thanks a lot, Suren. > [1] https://lore.kernel.org/linux-mm/20250227204823.758784-1-sidhartha.kumar@oracle.com/ > [2] https://www.infradead.org/git/?p=users/jedix/linux-maple.git;a=shortlog;h=refs/heads/sheaves_rebase_20250304 > [3] https://web.git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slub-percpu-sheaves-v2-maple > > From the numbers, it looks like config4 regresses the performance and > that's what looked weird to me last week and I wanted to confirm this. > But from sheaves POV, it looks like they provide the benefits I saw > before. Sid's patches which I did not test separately before also look > beneficial. Indeed, good job, Sid. It's weird that config4 isn't doing well. The problem can be either in sheaves side (the sheaves preallocation isn't effective) or maple tree side doing some excessive work. It could be caused by the wrong condition in kmem_cache_return_sheaf() that Harry pointed out, so v3 might improve if that was it. Otherwise we'll probably need to fill the gaps in sheaf-related stats and see what are the differences between config3 and config4. > Thanks, > Suren. > >> >> >> > >> > >> ... >> >> Thanks, >> Liam >> >> [1]. https://lore.kernel.org/linux-mm/20250227204823.758784-1-sidhartha.kumar@oracle.com/ >> [2]. https://www.infradead.org/git/?p=users/jedix/linux-maple.git;a=shortlog;h=refs/heads/sheaves_rebase_20250304