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 C74C3C282EC for ; Mon, 17 Mar 2025 18:56:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2E79280002; Mon, 17 Mar 2025 14:56:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B896280001; Mon, 17 Mar 2025 14:56:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83239280002; Mon, 17 Mar 2025 14:56:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 62BD5280001 for ; Mon, 17 Mar 2025 14:56:38 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 3EC0F55B4A for ; Mon, 17 Mar 2025 18:56:39 +0000 (UTC) X-FDA: 83231949318.08.E913D2D Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf16.hostedemail.com (Postfix) with ESMTP id 527A4180004 for ; Mon, 17 Mar 2025 18:56:37 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=adH1xVT7; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742237797; 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=P2MTPS82nJIqHJWWsdQh9wX6LNPhF+HHONa8cgA7jlY=; b=7l9NxFhQJrF69+w3zXYoeSIb30adzuosa3wEUoj4w6ZCgOKdm70u5Lz5P6dF+MIzrjX53+ 3TTRI5nQXaWnTljuRsMLS/Lx9O8vk0ErAo1gCECx5lfDcn5/sWAh4SQtOgf/oYbM/ymmGl 0DrA1hO1czwri1XaSK2oR5yIISZIIbE= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=adH1xVT7; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.160.178 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742237797; a=rsa-sha256; cv=none; b=CiUdbyAFiSpLoijP/H8Ghs2rGIMO+oaVhUDJzNUqv9YueyEU0mPFG0GMJEtQvMIl3QGCtw 07wIt4lNWEO/UXb724J/Y6SjWqJC5XWtvKNNSPpvubPwhyKtqzaLUEs3UFuI8lddhdHOUV etaSMNZl3tQ9bZdsC/hffB2JK95llHs= Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-47666573242so30271cf.0 for ; Mon, 17 Mar 2025 11:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1742237796; x=1742842596; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=P2MTPS82nJIqHJWWsdQh9wX6LNPhF+HHONa8cgA7jlY=; b=adH1xVT7IyShFBVmwlzkUlL6/09wljZIj+rjIbVYxIJvTbuLFqQ1yL4xUndnTlAwu5 aRrObG2I4wf3OobS8+VUzlDDqyoZ6AHolgrl9zBO90Hkpzy5w7pWSngCf1G2+WujfC1Y uzaS2lNKk1wrr11BqJt6Ne7VqXlVut5DmJJ7OkFMlYFxIhVViOazG0JzHYZQlYXA5U1B C04bmLE/+psyVsTg7PtOg4yPFHQ8IBfFpwMvsNmuwEuxvOHqt7cGoMFd62z+wQ2j7XYW BgZncvgY33ifmbGIPmNtKaPfjkOKrivfIQbCLTOK2pura/uemmrYr+Ay9mI3rgSe2sDK jslA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1742237796; x=1742842596; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=P2MTPS82nJIqHJWWsdQh9wX6LNPhF+HHONa8cgA7jlY=; b=TWnynydgjoKISMAX8oAd/b1mbJN1FK9skS2MoFxAA09YurmchZQVylGJVKzg6V2Juj 52xksqGp3RH6jWy1J2gB4AEoZZXEgXg6YDdeIJn71G78dOb6nqR4OB7rr+YbT2XZ74la kn3cH5CXKG/SgLy90x3w0dZduFkhvwTPfo802WSjOJfXrrqYfFKdEKTHzSlpDTbYApxT Jg8kb7fwt2EihF7MhVsZ7j6T2ev8tCFeP2u7kD5rcPkdgkXJwkzQ7dcY4/9O2CDIHYkD Gjff/L18HHULk1EsbpApI9BMwBrdsOuBWudEPKk68GT8QWx/nsse/LXfMCWxHzn4F5m1 EuVg== X-Forwarded-Encrypted: i=1; AJvYcCVYTfopprzx0efucOi0jvuf0p4DPzN963yFRyRadp1u8ibiWa5A7/fITtdDsuFwMphbtD0TerPq9Q==@kvack.org X-Gm-Message-State: AOJu0Yz6mCCMFF7HQ0+rQ8MR6m1uqq/7cmEIbTJ2yLgp18mPzS25c9bn Wb6izHyJjmnKKqIFcLPJitB34SWxgZxCcDt/GGmwrRYVDdhCnlO0V4aPMolch7AjYW9F0SmRPVM FCFRG0FVUeoS/vJFvdvQvDYnNK3lWqtQpQkeu X-Gm-Gg: ASbGncvf5/4YXI5GelQJxAm6i2Zv7kEcmYwK0AFceRAoBftsO9Cm4ZIpvc5d/Z1ZS/O DB00LKE5Ju09zehhEPwGSpvkWB6hkD3wXnDd/V59W4TevNeldTKQkdgAVu0KEzIdCsWw9Lc95cm 6W9y0/UzdUsQlnDOwDqRhlzpaZGA== X-Google-Smtp-Source: AGHT+IHxhS0AFsGqJ63tw+5kUuQHboEma7CDZGelSpyScNouLrAfX+0ci2TYwytV6GKLPy+KpPN2c1zrWAZQtugNxN8= X-Received: by 2002:a05:622a:418d:b0:476:d64c:3a4 with SMTP id d75a77b69052e-476fd7352a9mr482611cf.0.1742237796062; Mon, 17 Mar 2025 11:56:36 -0700 (PDT) MIME-Version: 1.0 References: <20250214-slub-percpu-caches-v2-0-88592ee0966a@suse.cz> <173d4dbe-399d-4330-944c-9689588f18e8@suse.cz> <19df9218-c984-4cbc-8b5d-4e0f7658935f@suse.cz> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 17 Mar 2025 11:56:24 -0700 X-Gm-Features: AQ5f1Jp-bP5tyLKVEt7RtnCv14x5n4T-1IJfdl8gDBhMeAIjP-Cb1869hDZGiPk Message-ID: Subject: Re: [PATCH RFC v2 00/10] SLUB percpu sheaves To: Vlastimil Babka Cc: "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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: cjz8pru5r5boi3g8rir1ydwjzf8fhq3e X-Rspamd-Queue-Id: 527A4180004 X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1742237797-719276 X-HE-Meta: U2FsdGVkX1/SCQDzDMXKHVX3vYcOgoIjUo40+dYSF/woQHT+my1+TWr0vHjdFE4PvpZjYLZ8A5l/HUyk+3GmH141pemKrTVpV7vUz3pNLxGaoT9/LgeF9BECVV3orjftaDfiJWRRf4eXF6a0Pc/KKM6DPsve4QG8T2tiYvKnVgcUiuuel7xk4VH48fT7WZs2z24t8p3eS9fjrabQ3n9T7C8la0fppKUFlLoH6QG6qojGHNqiCegnvuLn22Yt/Lun5MxJJzxYqn9+rcfXhByMZqrsQ5OnKsmBzquFW5FHwfaDSpnYuZMBcuV19Ax3nz641Y3B/lSrULnsWk4PeHpENnmXqc8qmn8IJsEMah/8D2zWwgxgfxw79EggQiZwVQI4IsC2wK3oRWyr2jWcTP/K1t3qhy2z3Uz+Obq8p4hL9V6MAq5zlvXbZ5OUUNQDJX2ftm85LfvQl5WBIgbEM2iQXuv186bG0M1TwmdpL9uRzAnAdM4I8v8Of9qcD0XZB/uRhGzlCwCGsJ2mN33UZ45Oplkz2z8M7JZ7A1DtFxtEgcV6tjmHvr56yu+g1OavCv7WfTuBdoCZCFO4Q0TgP3qvGhiY6jKl04rSl80HqYRAnxeass9Xrdx3CG2XOUaShxmM9R6fYWsMNSf9uqPxFNWY+F7Mv4NdrLRMk3VdH0nSP35cHxPqEgeeFx8mz9KvQK/QDc7eXamz/oLlysS56UDr5N/Pdf16212po79NtfMAsbMPUvwaO/eIWqRChmr1I+c+kFGVvR0T6IzEkZMs9BtfI/HXByJD/K4n8xOMepMCPZbPZ+Xw/5r3RoH83FyDDLIaf9Kl7k4cpgPSf5b+1lIe9Thy/wouTFjt4uDN3wLvZiqgeTdgs7Zd2sd433CVwPdYNyrJdI/XOOCN4F2jKw1ieF0bvFoz3n18eL4tr0E0n1BGTqqvQ6u77jEUQeRpb0B8TdG1zcVbW0LqRpMK6FN qpLmDZCA 136C/YhG5/3+A8SeVqLN7h2tS4Tc4ZuWih3bczQw6ibsgfzyY2uWdR0e8HvrNLypA/keSdnSmlcO+k6IkKICREJ612DPiYmSJUJ/eO/+ZltFyVXlqQtqN/ESh9s4zmHZlYLVGaTfXLLpuvtoDrDsbFNHPgI1qN4zwZIgopoSkU04KYJiug/JKlMMOY6irzsoJ+FhktNVMkGwRM+xD6HJBVWgZKTGEkV6IC7dCee2kCzvAHOxqbc2SeGNqqClB64bn9WQMBHvrXJP7nBV00GCl0HvM9PCI2MZz9gCidj3rwn+dQr7qU2tG8/9uolX6La6HLZ/hMBKeNQh0xrbRoxlT2aXVw/X9hnEdWoUTW2VKhznw9Uor5/mBqZv+HHcqxHG0vcyO6QVUxpUmWU8= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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 Mon, Mar 17, 2025 at 4:08=E2=80=AFAM Vlastimil Babka wr= ote: > > On 3/14/25 18:10, Suren Baghdasaryan wrote: > > On Tue, Mar 4, 2025 at 11:08=E2=80=AFAM 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=E2=80=AFPM Suren Baghdasaryan wrote: > >> > >> > >> > >> > > >> > >> > > The values represent the total time it took to perform mmap s= yscalls, 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 baselin= e 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 u= ndone, > >> > 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 po= int 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 w= ith 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=3Dslub-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 mapl= e 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 wit= hin > actual workloads? I time them inside my workload. > > > 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=3Dusers/jedix/linux-maple.git;a=3D= shortlog;h=3Drefs/heads/sheaves_rebase_20250304 > > [3] https://web.git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.gi= t/log/?h=3Dslub-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 prob= lem > 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 wron= g > condition in kmem_cache_return_sheaf() that Harry pointed out, so v3 migh= t > 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-sidharth= a.kumar@oracle.com/ > >> [2]. https://www.infradead.org/git/?p=3Dusers/jedix/linux-maple.git;a= =3Dshortlog;h=3Drefs/heads/sheaves_rebase_20250304 >