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 024D1C6379F for ; Tue, 14 Feb 2023 16:47:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 550A36B0075; Tue, 14 Feb 2023 11:47:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5009E6B0078; Tue, 14 Feb 2023 11:47:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EEB86B007B; Tue, 14 Feb 2023 11:47:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 302246B0075 for ; Tue, 14 Feb 2023 11:47:41 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DDD8380EFF for ; Tue, 14 Feb 2023 16:47:40 +0000 (UTC) X-FDA: 80466478680.16.1A955BF Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf11.hostedemail.com (Postfix) with ESMTP id 0A42640009 for ; Tue, 14 Feb 2023 16:47:38 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=p2TLRP1L; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.128.177 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=1676393259; a=rsa-sha256; cv=none; b=1y+6e3ow/lvbkipcSzhwqKY6p4Tk0tfPhEg9Gh3HTrG0jxAeLyoXyekM49GyYNiDk9isQ0 gC1R8/EezzfYGoToTyNWi0pVfuET3zP7r0g0j8nfbtjQTwI99XefPjSYQTWGrzbl9rPRir qnw17Aao2kt4MoRrGrnh0TXjz9r+rPM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=p2TLRP1L; spf=pass (imf11.hostedemail.com: domain of surenb@google.com designates 209.85.128.177 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=1676393259; 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=/ayL3I3lSJXQSr5Jm+VXTau51rl41gfRsh35PsMQ4l4=; b=Aod4Q9tNKhTmERkmb9FpVYe/2xLuyw2NvOWM6GIZ2oTOrzrvgcywRy4naDYWyI6f/acqTr bBNGhVLbNEC1uEYqxq1XHTs/9p9C6uAq1thutxrc7K4gQS5VTeTGdkusdAW6bYObr/dk+N H+G1pneDZWMvebJnGJnujqYm1hY9ySo= Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-51ba4b1b9feso214358217b3.11 for ; Tue, 14 Feb 2023 08:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; 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=/ayL3I3lSJXQSr5Jm+VXTau51rl41gfRsh35PsMQ4l4=; b=p2TLRP1LQYRQFLiyDUgbiLevDu32jCQ1L/y8KHXKpM3qk3yQMC/KRusxiAUo/2I5FR akQzZTLXnxb+P1qBmss9iIWLDGKg0C359syK073euM8tuN5Sl/8WYF11lclUeYyAUpMT hAGRMYI/iF5fhJver2jb4sWSYvtAFyiBKJIPjFvWpjnoUJwPU0kqPytUKfvSHAYHbAg2 M09YNljijJZij+Yr4ZSoVYpX0jHEwLPIiBY9qadnh3wJ0BvnRF1uG1ci8Ku87aTVb1aO 81XWgOzFKio+DbidG2VtE3NpZSUFQFw5KG2e47GfYfbWHge6uJXUOgMZ4f80jBrT9T8b 1Jfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=/ayL3I3lSJXQSr5Jm+VXTau51rl41gfRsh35PsMQ4l4=; b=C7+VltgakCzKOIDMwNlolCevdtz/xOCFYbG2mWiwHs1llxY/Ds51LiadaXQ0kWr5XR Z25Zwsoc6cKd0pxeST4lfQzXOW+u48MqwkOP5sitHHdaECglqBWTXh3z4YvXt8cLbBNV nWv5l8p4hnRQyC9E+W5nZCYjyrCt0m8cOP57Q2dlMHkCiQ/qU8ARp+ngt6G3tBgLphck TFkeeRwuJREsYwZaUG+iEO8waZGDpgRiadrOI3lGK5fIlTcqgxE2sPwIq29muTC7sXCi cFBIIe2gwtNlR5LCYswmRq9YTExUsljDiecI3YOQRaAFgwkTs4Jc49DWj6AUh1MErEr7 6Vvg== X-Gm-Message-State: AO0yUKVOtWO8n6EaDrHfS+DiKmiktzLIiHh0huVdPB6ai2tJCICfKxtz u6NjNcnK6M6uOZGylSUtf4WagO1r1h6Z22PVZfe2Xw== X-Google-Smtp-Source: AK7set/mxOKdHn92cBwjyApj3R28pXKEhuPBGovIRR6cczvfLCLR3WjxmhojkFsLR3cVOKM9zEYVw0ts4tZUpyJ11zo= X-Received: by 2002:a0d:f5c4:0:b0:52e:c93a:bb36 with SMTP id e187-20020a0df5c4000000b0052ec93abb36mr319927ywf.277.1676393257997; Tue, 14 Feb 2023 08:47:37 -0800 (PST) MIME-Version: 1.0 References: <20230127194110.533103-1-surenb@google.com> <20230127145138.8cc44bf00ebf289dffec0975@linux-foundation.org> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 14 Feb 2023 08:47:26 -0800 Message-ID: Subject: Re: [PATCH v2 00/33] Per-VMA locks To: Matthew Wilcox Cc: Andrew Morton , michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, liam.howlett@oracle.com, peterz@infradead.org, ldufour@linux.ibm.com, paulmck@kernel.org, mingo@redhat.com, will@kernel.org, luto@kernel.org, songliubraving@fb.com, peterx@redhat.com, david@redhat.com, dhowells@redhat.com, hughd@google.com, bigeasy@linutronix.de, kent.overstreet@linux.dev, punit.agrawal@bytedance.com, lstoakes@gmail.com, peterjung1337@gmail.com, rientjes@google.com, axelrasmussen@google.com, joelaf@google.com, minchan@google.com, rppt@kernel.org, jannh@google.com, shakeelb@google.com, tatashin@google.com, edumazet@google.com, gthelen@google.com, gurua@google.com, arjunroy@google.com, soheil@google.com, leewalsh@google.com, posk@google.com, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, x86@kernel.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 0A42640009 X-Rspamd-Server: rspam01 X-Stat-Signature: dkpi8musiibbqfn7yu7af8gjr6knogr3 X-HE-Tag: 1676393258-58535 X-HE-Meta: U2FsdGVkX1/FW5OYwk+SaqPDYZLeYd4d1x2CUWhZ9qd59GyOVrlVULmk1FsmjwcETHZxwOyDVGJHP2VvgFEkmsOgx1Bzr6kvD6iQxEXnh6/YeHauw0csgE6eII6pBb1PIj88nhDHdJATusw0lz9t5DEpKQbI5W+s6pMG0W1U4byiiPOJZbKo0YmVFrjWjjRei9hEWLLMT3WuFubQ7NuROBXW70fPRACha6FhEgNea71BMkgjXh1jg++ZpkxvR5+xgqUTan71dgSJvti8P3p8qjvOjFneCJzPZNGY3q3CtIy7d8pkSTHRhCObJWfn0KYRqoNJoJVRf4hOn/NpTRJ3qyfCyGypy3EWQ+aHDmjiWruuJ/juNGiAPgVf4HJjI5cdjod5u8HsEQJFGPLVVxscKi/Sm4PGWeKC5sA9lVD0SyuLEdK+WLZ09Y3iElLnBma8Fy/iQEZ/0LxMBtagdOkZPT6ZTlC6wIQM+SEEUIwgFFzj7aoTi6S9Nadq2ybm7hTpnB89uhiYdYJq5kh/EnWihl8HmrxGzB/IjgUdsfHtaV2oFCx9vK11t8YlKRNVbVXBKysiiEBrtrExaYG+Ux2huDirMifdJvZCXcAAkNq3iW6AYFWnYwL1Gz/37wUDNjQ3tVbgGpeiTne6Z8ZOhaTVAswIy2btqVhhqLUOW+k0DjolB9k6REtGl8yfH1ap/Hcbj/33LD5uV3zspruKews4ziql0QGVN8NxUs4GLyh+2hsmQl1eHs+XB3uEI/9wa0UjAjN/V7g/q5HHRTPipD1ndRnWSIwHsWmoINGejl/hJP81wIIykm/W01QpHjQyTR9ZubA/zUgre4YdDYIu+/tR2IzDTXmjVBkCOo5OXe+8CH4BPfxHBNiqvz9pTmnfs55mBe0nyIZM+oijr5ge7FMhy7irOLUQQm/DYM+doD6z0eN7k1Sas6VLa/7gzYrZ7yDF9U8GpPkh1ZBJ5rYKgSH 5hbnH86n B7zGJMWrHpMh/iqBPBrq2yJbwk8VIiL5JCCt/F7a09vpjncGTxAYokSMcR6abmqPJ/hq5K7NFg3hkA8H1jGf3aC7noBr8bUyKjlsBDJ0fG76J0FIFjlVqU8ju6a6rIfYhA92M2haG6X//TiAOu+uv+6Mo/Kk8mlPC3uVW8V+ldFBc4t9tUbqTElQdijF5itroZYD8/diq0K5BVnwoMVuPWf13EjBCgoojwv6cpBOX+ch7MyUh4poVMqUtbaMAXYPgR+wnSUPzaIAWnd+ZqEpnhf2abwRBfdD0umfBUYHJA69kyCfX18ZcEuFgNsLwip0XNBZ1gDgRv7yh3LY= 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: On Fri, Jan 27, 2023 at 4:00 PM Suren Baghdasaryan wrot= e: > > On Fri, Jan 27, 2023 at 3:26 PM Matthew Wilcox wrot= e: > > > > On Fri, Jan 27, 2023 at 02:51:38PM -0800, Andrew Morton wrote: > > > On Fri, 27 Jan 2023 11:40:37 -0800 Suren Baghdasaryan wrote: > > > > > > > Per-vma locks idea that was discussed during SPF [1] discussion at = LSF/MM > > > > last year [2], which concluded with suggestion that =E2=80=9Ca read= er/writer > > > > semaphore could be put into the VMA itself; that would have the eff= ect of > > > > using the VMA as a sort of range lock. There would still be content= ion at > > > > the VMA level, but it would be an improvement.=E2=80=9D This patchs= et implements > > > > this suggested approach. > > > > > > I think I'll await reviewer/tester input for a while. Over the last two weeks I did not receive any feedback on the mailing list but off-list a couple of people reported positive results in their tests and Punit reported a regression on his NUMA machine when running pft-threads workload. I found the source of that regression and have two small fixes which were confirmed to improve the performance (hopefully Punit will share the results here). I'm planning to post v3 sometime this week. If anyone has additional feedback, please let me know soon so that I can address it in the v3. Thanks, Suren. > > Sure, I don't expect the review to be very quick considering the > complexity, however I would appreciate any testing that can be done. > > > > > > > > The patchset implements per-VMA locking only for anonymous pages wh= ich > > > > are not in swap and avoids userfaultfs as their implementation is m= ore > > > > complex. Additional support for file-back page faults, swapped and = user > > > > pages can be added incrementally. > > > > > > This is a significant risk. How can we be confident that these as ye= t > > > unimplemented parts are implementable and that the result will be goo= d? > > > > They don't need to be implementable for this patchset to be evaluated > > on its own terms. This patchset improves scalability for anon pages > > without making file/swap/uffd pages worse (or if it does, I haven't > > seen the benchmarks to prove it). > > Making it work for all kinds of page faults would require much more > time. So, this incremental approach, when we tackle the mmap_lock > scalability problem part-by-part seems more doable. Even with > anonymous-only support, the patch shows considerable improvements. > Therefore I would argue that the patch is viable even if it does not > support the above-mentioned cases. > > > > > That said, I'm confident that I have a good handle on how to make > > file-backed page faults work under RCU. > > Looking forward to collaborating on that! > Thanks, > Suren.