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 126C8C282EC for ; Fri, 14 Mar 2025 17:10:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79400280003; Fri, 14 Mar 2025 13:10:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74403280001; Fri, 14 Mar 2025 13:10:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 60D1F280003; Fri, 14 Mar 2025 13:10:37 -0400 (EDT) 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 448FB280001 for ; Fri, 14 Mar 2025 13:10:37 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id C1F7C121097 for ; Fri, 14 Mar 2025 17:10:37 +0000 (UTC) X-FDA: 83220795714.11.8AA7A7C Received: from mail-qt1-f178.google.com (mail-qt1-f178.google.com [209.85.160.178]) by imf25.hostedemail.com (Postfix) with ESMTP id A9D9FA001E for ; Fri, 14 Mar 2025 17:10:35 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RHihD54I; spf=pass (imf25.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=1741972235; 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=8EWHBV9blsC4VUtgf9tmLM/z12+DckHNCkeHcX1VEX4=; b=kcoilKsmgzIVoQFz88fMiQ9ubEQ/2VHe++Rm4F4/Q/rw36Kwod0YXv9btSXcKVU1YDXKb4 VYfY7K8aAHLhkSoPRIgR3e7iLP2SwhABMaMmen/AD7zxCzxVHzioKtv3NhMXMmjtWGv0z0 Psjussw73e+O7NMHg8gq66xcjkhM2wM= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=RHihD54I; spf=pass (imf25.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=1741972235; a=rsa-sha256; cv=none; b=3XnjVHkY8zWFDFZhuO5+dXmPUOjSjNCtTqj/BEpPGwA3J5GEfe39hganSe7CDAxx1rEHDL zEIzH81fBL9aaynVlubafOtmGDpK6i5xxTLm9pfAkTNRlmlKGwxzmUZBd4pEY43QiydRD4 iICaKPBe45Qu94s9ADA+IBR9jZqewcA= Received: by mail-qt1-f178.google.com with SMTP id d75a77b69052e-47681dba807so7471cf.1 for ; Fri, 14 Mar 2025 10:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1741972235; x=1742577035; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=8EWHBV9blsC4VUtgf9tmLM/z12+DckHNCkeHcX1VEX4=; b=RHihD54IemflWPedG7po03YIJiYLqJKrKmtD+ysq0E0gIaD9uHKTLvH2wkWDazQQnM O4ogVqeqoZXBvf39calDJVgs8/6X71gcVenQRxUAhAuzqkGQL4aO3QL1CJUcRHq5xHIs vYcK32xW1uOC6Y0+bnqNnJKv4UdMIGbjyUJzMQx/Q4urI98/oZ+iP1veZMhQyJzHO0JA D7kJ4vqOfpRWoh75TOfrSnjOINzRs+P48iX8UY8ItezHpRA45KBq1qXIM5r+ffawYVn0 qmzfGptLsdF/vkKWGGytw6sC2CrleZhhEqDuyvngcopMblgA6p6RoIkWxytVEdsdnU42 c+zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741972235; x=1742577035; h=content-transfer-encoding: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=8EWHBV9blsC4VUtgf9tmLM/z12+DckHNCkeHcX1VEX4=; b=Nelz/XhgvX6uPvdkArSJQKJ86MNk71yK4CxfdnrLb05BHtI+hZWUMy2r37N8FBJgHQ Wb53D/1ED6eodk+VwNFjmQBRX+0UKZS7TFWJWYNwaNszFkYbkrRFd5zDfy5K/kp6ZHYv UnRj28+DOhV9XtLdp/ok5pYOKzkUgShnh6CsaXJKdsMelGI/8xDnGUwj4/vokO13fq+r 77zIM3c4WMY5YnUQIg0h1kYzTnvoQ752QAV0jeiKJknqmSBxaWiLyF35DjECckDU4A27 yvIQTXb5dkKytLZccV7qDqIoHYSK9Yjkcjjjwg3FMrBv65GRTH3wE2aUaaDg6wjIJx1J E8cg== X-Forwarded-Encrypted: i=1; AJvYcCUBaa5ROOyxkknP4sKBZEbJX9AH5EtVeAdNEEOd9VApEsO/pSDvIXktMBMat50Y0VIPKanM7Rt7pA==@kvack.org X-Gm-Message-State: AOJu0YyUVsDoL8zr4Icr5lGrxBWfOhe3WPjJF8Yvlry2Id4q+j/3YA5q /hYO7pBB20mK5EIMrFwQ44ta+OZZsxeeQl1AuEJjZk1F+Yy9ygrqoXQU7E8Y6+Q9VvV+zXGtALR vWYojHuC9feAHGQOwiKWPWb0d/NZNnNlAxyMP X-Gm-Gg: ASbGncufdYChAX8ek9QA+uSrqmkhAx0uI/C2TlkmMpW4oWy+BQmcfxlUkvwYWjpxWki eYjXAJk/Qw8zn1a3jWUOGBB4+oSdhD3gG2GEShoXwXNXkcp/yyrtlC8AFmeWMOzAEno4GKn7Cbb 8Dc1YUCcLEmyt4YMhxGOdx6c384g== X-Google-Smtp-Source: AGHT+IGJHHQF4NTn6NB5LyU5PLdvXbvdu8URRo9QL8eVBvNhUTnHirCkG4lnLyzQ9QiIKZuvzTbY1DBtZlnZfbcpR3A= X-Received: by 2002:ac8:7d0a:0:b0:466:8887:6751 with SMTP id d75a77b69052e-476c7fe8345mr3392701cf.23.1741972234384; Fri, 14 Mar 2025 10:10:34 -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: Fri, 14 Mar 2025 10:10:23 -0700 X-Gm-Features: AQ5f1JrG8no_e7JHX8g1zQia30PtCt7dt-uwm8dg_Hv_0Iod5LHZmZ0lPg9sYMk Message-ID: Subject: Re: [PATCH RFC v2 00/10] SLUB percpu sheaves To: "Liam R. Howlett" , Vlastimil Babka , Suren Baghdasaryan , 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: rzbno5z3h5jc1umk5swh978wc9e3674n X-Rspamd-Queue-Id: A9D9FA001E X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1741972235-158802 X-HE-Meta: U2FsdGVkX1+OPB1wn+jvkr2D6CjOAxu0N4c+3qTVR59wolB2u5oW/c8vQlkoj1zJFewrr6p3/KcRMUaFB8aaLlE5KdpPz7GPr+sjBD2LDwclbTn0pbcR0ksd7GV5dfu1UYIY3NqCGZqzcv8VErhk/jGwEk0V97p5nrFLExxKV5KuMPXEDHxkYAievstxsXSV6k1wp5/YE+X2qSuga2hzTQR8AvvXULAJVXB0cYzt5kWFBqj/JMpzQgxYh51ZArh1OeYJ9twsreAIVJxxrKL9R2OXIvwRF7c/dpqmdn2RPW7zYIjzeqfI2c8BpcsQ6uOGmFNpnhFOAen18IM43WibqbJN/7GB4IXZ4nLE6JDv5L+BY3ehc5ncyvL/zhPCUH0lHUsks5ThqhTavLbrzRmpFSeEn6x/RT27+bcWSn0wqFO4Ljw27Pmzmm4KKC+4v3OvjY6fMkNlWCOeEn+AKkzuaf+hEeYlkaID3VsNdPYigcRJqpX+kXzoE2ZsqnJ+AR0+b9Oek64BwqBvXlishWPKx0WH/hQXwWvs1yj2TtQn8cLtDReEnVBrMLiv1TJZJqYocdxOfRu+vBYDewEzc02/VSc0ZzYDmwoW691Ek12LsWFiYdIlnQakXh2H59PgtgsxQwKq6akPmEcBBx16i944rxduHA6XKRWGHz2HJj9/Er+HDORr8MP3uEuZkS/QsaO57439ZN7YSVKzrabXlZ5elckfUVmbXA8s6rPylWUwwK0Im3D+LcfsoJaYloD1/Xk9vfB3EQbSkwD9C76d3Ogs1VxBNbbplcg32ZbD7H0Cu1Uj2+L2AXxU59gyv/WvdGIB3bpjzTQcYiXJmv43doClRaYdWWIBTzWw/WIzL6d2w0RClli6vsRKXSfk3VQ933luISIyTgoYECVGj6eBaQMOQWdQJT2jcWXRGpsE5eZZazWyTnjLmFJvo/2trR6YDS5Nv1orjIHarsdj8QSNv2t JepSs1iH npLulQhY5fhz7M8YjBMAFmsGhBk2aGpigT+R4ZuWlsjGWrD7y3PWTH9k0IZf6/lRGyfjx3Jpgg1feWhoxcoZ5y1dNmZIdiP/YfaYp39NPEdemiKx4s3GCJSPKZNDwuw3gZ+346yXYa86lisGgamPFJXFuC6mDxeIHmfBP04p4aw43+3PUqRQuppovaQCbAIjbWjQrvbyBSwLZSLq86RhXzNHzuEeGrH5BaCbqassZ5ovRVrUJJ4fT1FxPnROr0KgKU8T7ueTKWlv3QTe03F0q/EwajlFj3PDnc/tufDWR4hQ9RU+kKCc+qzS5a2DIxqmy9uHswgyaM7hSWnILIyF5Onnl5NmNi+TKbTymCwoGitDhB6L78GvNCDlQIZ6dla9SPtgQ8YEfR3IKxV4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000253, 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 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 sysc= alls, 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 t= o > > 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 po= int > > it's the vma lock conversion including TYPESAFE_BY_RCU (that's not undo= ne, > > 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 us= eful > > > > [1] currently the 4 commits here: > > https://web.git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/lo= g/?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 maple t= ree > > 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: 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% [1] https://lore.kernel.org/linux-mm/20250227204823.758784-1-sidhartha.kuma= r@oracle.com/ [2] https://www.infradead.org/git/?p=3Dusers/jedix/linux-maple.git;a=3Dshor= tlog;h=3Drefs/heads/sheaves_rebase_20250304 [3] https://web.git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/lo= g/?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. Thanks, Suren. > > > > > > > ... > > Thanks, > Liam > > [1]. https://lore.kernel.org/linux-mm/20250227204823.758784-1-sidhartha.k= umar@oracle.com/ > [2]. https://www.infradead.org/git/?p=3Dusers/jedix/linux-maple.git;a=3Ds= hortlog;h=3Drefs/heads/sheaves_rebase_20250304