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 153DEC05027 for ; Fri, 17 Feb 2023 10:21:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80DF86B0074; Fri, 17 Feb 2023 05:21:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BE2B6B0075; Fri, 17 Feb 2023 05:21:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 686176B0078; Fri, 17 Feb 2023 05:21:38 -0500 (EST) 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 5A9EF6B0074 for ; Fri, 17 Feb 2023 05:21:38 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 21206160C6A for ; Fri, 17 Feb 2023 10:21:38 +0000 (UTC) X-FDA: 80476392276.14.51D1A29 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf30.hostedemail.com (Postfix) with ESMTP id 71C848000D for ; Fri, 17 Feb 2023 10:21:35 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=myOxV9ga; spf=pass (imf30.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1676629295; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=H9BBhPTLGGaUBxW3AOHp6ZsKFR75sYiq19lXrasIXls=; b=2AhnK4fByZgvapPo3NTqImRiZS8QzMYoJTLaFuISN2QVOgitm3dQnagM0pyJdJdUPOO2nG K7nDLUN0l6VjyvvZk6S/GyLdfHrOFKk1USW82ue/fG8zCfwLs0XAXkEZrT7HBfc/r19Y6S CMTHcAs6jEu9M2DkgVnsigi80dHZLXQ= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=myOxV9ga; spf=pass (imf30.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1676629295; a=rsa-sha256; cv=none; b=PtUnTZDfHKlNaQ/nATpL/DAnu1deK1VzIhkuiHtHA7oqUYJSjgbS4ZIEH5Gc4it2kyeaEP 2BY1QSaBDSlxzGGoAM/BBSjQxsJgbcFMWOSR8FMrqxg1Nk5u/Eo4MGES1MVHbTxeU6OH7/ 50BgcHBfjta92fMPxjB+PqglEMWOfuw= Received: by mail-yb1-f179.google.com with SMTP id 10so754608yba.3 for ; Fri, 17 Feb 2023 02:21:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=H9BBhPTLGGaUBxW3AOHp6ZsKFR75sYiq19lXrasIXls=; b=myOxV9gamhIWyliGmdmN2/mk/L1tbECLokR9V0fsZYL+Aj/t5D9uNxFdPdzQY8b5Eb thUND1gGBMTB39ipgJZf2Ql2LwujdfXsd2EzrT0IKVckNP1pDgIt9Lw3ICJtr2va/jkA WiVF19oUY+8ELCnfLAH8YG5HyU9uEcJ7o4MYoepq66YAimbAXisPnHBVOsYIERKI9ViL ty30kR8wtoIG+qnXXowYn0X8x22Hf3AhdUqHDULpynsgtTJmn69CgLLXR2KaH0cSsKFu 3jTW/4sCmj6lx99hEANBNFSMI5FxNAw7CWRBuN7NnhQp+zZF7xQg+Fa//77roL19p0Kt LVlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=H9BBhPTLGGaUBxW3AOHp6ZsKFR75sYiq19lXrasIXls=; b=1EpRE3zudK9UBGJm330BMXID8VXq+7nOERPF1rJoO5X6pL5M5+JaYktUzBDoc+LkF4 BXYDcGtUcWv0LicyqhmOw5PaBLLkNmrGudKy48WC119KOJSjc5XyiDZI8sgCKzoFxdAS ysFUUDWDmsDl/VTmOemGEuMsXrbieyH4IbV5+D7P3m7LQjjEoIQTcE5ep6NDFpekXSih K4ke4VBN/FmbKoXRdLGi/rK2LVjP6c6n9wdrTojB94VbjEEEg67NzqnyTa3FW8/ZOmB7 aD2IlxP+u04hYaga7MXk+uoqfzIaf+vmgJzGxH4UY2cqKknjOhG2NgPbJInZpw1BRNzm LfNw== X-Gm-Message-State: AO0yUKVx8eszsjsvawI5+iTSIJsInnmIZEeIgMbAIMMEGXayLohobvR9 6jhuUNMHygysL+PSuJI6hZNLLI1gFqcUo4j9bdo= X-Google-Smtp-Source: AK7set9XZzct7X7WLcYp9C1YQZ54GdA3ZML/EFmNgnNLzMxsPTlkXoYn0KU+aTYkj1KX4pt6o21ZLWxWDcs5n3vh8n0= X-Received: by 2002:a05:6902:308:b0:969:a7c9:d7b8 with SMTP id b8-20020a056902030800b00969a7c9d7b8mr386954ybs.624.1676629294516; Fri, 17 Feb 2023 02:21:34 -0800 (PST) MIME-Version: 1.0 References: <20230216051750.3125598-1-surenb@google.com> <20230216051750.3125598-27-surenb@google.com> In-Reply-To: From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Fri, 17 Feb 2023 19:21:21 +0900 Message-ID: Subject: Re: [PATCH v3 26/35] mm: fall back to mmap_lock if vma->anon_vma is not yet set To: Suren Baghdasaryan Cc: Matthew Wilcox , akpm@linux-foundation.org, 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, chriscli@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, michalechner92@googlemail.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" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 71C848000D X-Stat-Signature: e63njhnihhcybiguy4z31znm8wsewkgx X-Rspam-User: X-HE-Tag: 1676629295-646571 X-HE-Meta: U2FsdGVkX1/B4LM5PmiyXFsoKm3hl/1NbOjbsA1cdXobIfV0s87tgp4KMmw8hDBjx4A1SOeUsO2U5uK5TG0ZcPFIyqHM3y9K0tnJnHsyAPhix6Nb5WonY/mxrACDu0kKMYPhL0gbPBZReYDnH7HmHM9IxNd8tIoGXq9BosgLhb5z2nIjnN/OWSmXAf+LZR/yxOeS+PWECSpNQcGbd7MgTXCTWY/rMR68+/s94KGEyKJEja08wg2YO8MRhU3s4c/dhpdJfwj9IhizX+qOuY+VbO9lZjQJtITChJr9Rta2t2KBuW6xLZpXiXserqUgOznedQA2CT8mhXAJoKtMVxTd+eflG6rElKeg4ODWz1lSlMyfo9WFrpQSXyEYs9KtadiUYv/HNYENY77ajynIROMOgPxz/S66Icdlljo3Xf/JqLtcTvaZ++L1hmVkfVb/vgiqtbSsgdMkGYrVEdIXlELDtBW5qnbjRC4fzmNaFQDJ6LTNyGfayTmPGCOBsH92Z2FIm2r8mu+eFxv4mCUMC4iaJDW+Bu8oN6fBE2NMM0eff8hfBqhkK/d/1p3p/SQm9BG9I3zC3AEsfP1rTE1TwZlVv2ZQ8vabtgVmLfoGwW/anCLU4w1YL/083QFhSjgOaqa6SgnYhL9doAOwLyOD4ny3Ak/8PJjlv4EQgwNZXvJMfDSmfxTz6IrAaqiw+mhFyitI3A96XyJ8VIQz4xLsaSOf1jOQSCTnfBHfiSQbKVJLpxVqgaSkd4w0AE/vN6drr3uQeoZrHEtcGAEd0GzT+0sXgZWx+WHjSRyrCVDAT0a2U5bHv+WQ4Y/TuMBKXlEON8c45SYS8rbYFNNuAjcPUxMBIhZCUwDcbTkS0glKkc+n12MTbxkIakY49oAl8ipWzWrUHRgKvXKcd088CVrB4Ke3jCCI/nxyqdOUXMeb9VZ2hRbvr94tg/i9sMpnIbtil3NmmVxmFFUcOD8QOZJxGW8 h85cNMNy n1mQdmb/VRPUrs1Z2a3AsRqM4GuYJ+x1Q9RV+AvMiIPYsorJh/Vuye45QxCP5WTGFH9QXU/kb8Dr1nK171fJQvl2/JNo56e7XHQRXPc+3rI8eRTADGTmj2sB3KMp2TFqHRQtDystrdGGgPFlQ1yi7Z9WErY0/3xlHxFGpLYampbLXBCA4t0/oDL2IQZM+2c6nNfErFDVdxgEEn4r9ASsVqVLFtPMF+h/IPT2BycNNvSOB4lAyBWFCFkU3srBigDbrUlnCGTBZOvE/qz2BocKbg4s9y30/vBKOsHsQB2eR470RdnIMlGYfYOIqSgtcIyTn00OTv62LaGHz+jdb3hhgsamm1vs63gE6Tzy0NiXlHIdiCQIWPYL+I9iP79DXGcrr6MCxGPEeDXmW9Au9wfkIV1PsM0r3C5+uGtuHPHJqC2u6SewA5cpqYUvb1bUIy/0DxyqUxu6VIjwim+iKPGUQQfkXjiINj2cFt/5MtsZXdjWEfR+DQBuCdErx0FiEJI0Ad/+wjN2nXEv1BsWM426kCspXgA== 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, Feb 17, 2023 at 11:15 AM Suren Baghdasaryan wrote: > > On Thu, Feb 16, 2023 at 11:43 AM Suren Baghdasaryan wrote: > > > > On Thu, Feb 16, 2023 at 7:44 AM Matthew Wilcox wrote: > > > > > > On Wed, Feb 15, 2023 at 09:17:41PM -0800, Suren Baghdasaryan wrote: > > > > When vma->anon_vma is not set, page fault handler will set it by either > > > > reusing anon_vma of an adjacent VMA if VMAs are compatible or by > > > > allocating a new one. find_mergeable_anon_vma() walks VMA tree to find > > > > a compatible adjacent VMA and that requires not only the faulting VMA > > > > to be stable but also the tree structure and other VMAs inside that tree. > > > > Therefore locking just the faulting VMA is not enough for this search. > > > > Fall back to taking mmap_lock when vma->anon_vma is not set. This > > > > situation happens only on the first page fault and should not affect > > > > overall performance. > > > > > > I think I asked this before, but don't remember getting an aswer. > > > Why do we defer setting anon_vma to the first fault? Why don't we > > > set it up at mmap time? > > > > Yeah, I remember that conversation Matthew and I could not find the > > definitive answer at the time. I'll look into that again or maybe > > someone can answer it here. > > After looking into it again I'm still under the impression that > vma->anon_vma is populated lazily (during the first page fault rather > than at mmap time) to avoid doing extra work for areas which are never > faulted. Though I might be missing some important detail here. I think this is because the kernel cannot merge VMAs that have different anon_vmas? Enabling lazy population of anon_vma could potentially increase the chances of merging VMAs. > > In the end rather than changing that logic I decided to skip > > vma->anon_vma==NULL cases because I measured them being less than > > 0.01% of all page faults, so ROI from changing that would be quite > > low. But I agree that the logic is weird and maybe we can improve > > that. I will have to review that again when I'm working on eliminating > > all these special cases we skip, like swap/userfaults/etc.