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 E5681C636D6 for ; Fri, 17 Feb 2023 16:10:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5D2A26B0078; Fri, 17 Feb 2023 11:10:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 582EB6B007E; Fri, 17 Feb 2023 11:10:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44AA96B0080; Fri, 17 Feb 2023 11:10:50 -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 356366B0078 for ; Fri, 17 Feb 2023 11:10:50 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id F1836C017E for ; Fri, 17 Feb 2023 16:10:49 +0000 (UTC) X-FDA: 80477272218.14.CBBF95D Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf18.hostedemail.com (Postfix) with ESMTP id 1C3DA1C0034 for ; Fri, 17 Feb 2023 16:10:47 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BIBUTCtL; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 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=1676650248; 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=PFNFpEQr/wV6J8ecu6kCjandJU8AZ1ItdrwAe6ofQEU=; b=jt1/foVykiw1+pgK52jChCO5lKJcOO3sEZyEoI7DmJw547kP+njDngo59SGURG73ZULMhn fN+reCzuvRGD2TkSZoDBN9fKyT9CetVk9wmHgBzZPDSNxCzfDpgrsti7qCLPUL2UJuT7DR 6ktaisHIHNndSfWrGicW3tJBjBJdZhY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=BIBUTCtL; spf=pass (imf18.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 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=1676650248; a=rsa-sha256; cv=none; b=J3PP2dg+7yvTZb+qKpLvkCBki1W2itMlMcyG0JMBtzWZsiHxBk7brFOi4TlIc5cuZso4Q7 B9G7ExcvsTxFzTjmWQauD70u40rxFcrRAp3m3ifZ9BE651afVRarP+l76jNgleI6oi+jA0 ny1k8klkgsPGnoNsnrfq6cpbtHk04Rk= Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-5365893236aso13203757b3.5 for ; Fri, 17 Feb 2023 08:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.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=PFNFpEQr/wV6J8ecu6kCjandJU8AZ1ItdrwAe6ofQEU=; b=BIBUTCtLGNgOeX/rJadBXrsOuJ2/WIKkC9LptUd9hTOMhrKGH223slhsaq0Tguv3Cz Dd/6NKwGbYiRd+Lsr7BWUqZMAVGTQndQiWRAjnZF/CVl/ouXTLLw4PAn6FQRq6iBv0tU Kq59V4SeBS77l3W8l+gCWEg6Thq32NdPyKYnxl/rggkX+eYdPw8uq/aICJQNdY1boKhQ tzoZZDlP6n6A1LERdgtiGjkEDNOJKXNN5pckjdMSabAlEFdNEb8P3sHqoWVlKwIvn9rI N7YHPIENcTPC+/lTUav4KcsUPXwypDmjOCi0dSgGJm4xjhpMDAqGbNQ64lDOBZ4AcKXm HHyw== 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=PFNFpEQr/wV6J8ecu6kCjandJU8AZ1ItdrwAe6ofQEU=; b=mAlmvZKLkLTeDh6hKkaCbMPjym5lYIT9bTNRYzhnGxXechwSThYqtaZl4C6NT+XRiK H6vuZdDRj3xAdrsg3l551gNGwWxo6VYecoIhU/R9qnr6O95IR2+UxPAby/n+lqHRffHU SPdYDMFFOt+mLEn2S3P1TXGa/7bvDddEtpIMo1zLeTjz4ggklahadTm7mA9WhYbMP0NP XNXehb49HTDAVM7FmfVhLdyaxfnhnxrvvtYhGKoMemQ4VFEnVlpGkgpLpoGb7cKqJD6A fIvPpQM8ahyvkg85+J6TB6/lOmSbKitwUmXYHGTxheyjhiUJSY6cYTtcaTqRdPG3fyTd RkFQ== X-Gm-Message-State: AO0yUKUADaK/TrrgNGcPzhsToSOcwPU9ZvqUwGKbNdgzW51SxezqIGKR WvUKrT5rg+7Qu8x3wJdKjHE9JFqIn1CryeT1TJu9kA== X-Google-Smtp-Source: AK7set/f5GlkwKOfyDUfvguLjocwuuJ59RkVrqxPVxVbH90lYV8iKuA6tb3DgP9li1jq/Fv1wdtVUPHDZTSi27WK5tw= X-Received: by 2002:a0d:d54b:0:b0:534:c230:ff14 with SMTP id x72-20020a0dd54b000000b00534c230ff14mr316390ywd.7.1676650247072; Fri, 17 Feb 2023 08:10:47 -0800 (PST) MIME-Version: 1.0 References: <20230216051750.3125598-1-surenb@google.com> <20230216051750.3125598-27-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 17 Feb 2023 08:10:35 -0800 Message-ID: Subject: Re: [PATCH v3 26/35] mm: fall back to mmap_lock if vma->anon_vma is not yet set To: Matthew Wilcox Cc: 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-Stat-Signature: a6944na8yjw5h9ai6uh6j595o6mrfqpe X-Rspam-User: X-Rspamd-Queue-Id: 1C3DA1C0034 X-Rspamd-Server: rspam06 X-HE-Tag: 1676650247-910253 X-HE-Meta: U2FsdGVkX185vdHtmYwOxLAJC6D3T+lxsUWx1biK14xIC06AZ+UU3ngp2AEDj3ncNLSOTTITCTOjJeGhzy2+5KDhitTQAyiBP43gvdA7qU64I30BJQ5E21fsEBal2KbS7r26dZGjUXriH568PAwkeh+JQ+a35RCL0NJW3+m6EIhzpEX1F9DwVTWX4H5It5O/KsGnqsvBDzKoOFl6iNvrG4xyv9hfl+y56nrfW6sxbekJRolphTauO7bVFY+jTF1MhKLyeWe99IDOLOmtenmL7Ch2pCtupDjMjgaXtVw7bCTotF2zKqdWQhoD6T4uTdkPiu/PjhjFzVwY9pcUxFvvadkLTOB7ytnFFlg78CIiPWo2jQzXn1y8+fimtOquIA47fdQC2wK04Rn69e0KkstNPK1vCrGZhY4fWW2PzI1+juSe3VjAgU2s2Y0DYu9KcaBnP0klTJvbT0cNU9TSXT+NWVBvLvRaNnL20ec93YU1pUcmgvdAEW3NuJUgt+Kox/jYQZrCStwcqqVBlxuLTHurV4XrLrDGh4QqpUbDe5Mx7urXnDBH0BFcJRx4BfbZDkXDEbQUp5RX8ppaX6LIo9Nuy7FS00ArLGjAxUo7AmIb6B/upRX33LsELW98rRO1UGrSTRdhUI8Ql+eETGsp3jOndumrHzHn7BFAQDLpXtukuFKBVMvsPY2HkvMmwvuZJkJF0QaE6iWSPg9H2O0FQNCHg6gQrB8G0hxJA/1ir8r6Hl6IG1HJ8aVlj3Pk/W7fT2X4Yq7LyOdvF1wMbyMIS/6N8IcixP2MyPjQgD5W+OK6b0isO0C9W3C9Gr+ipHYBiqITedmXezF0qDxv35mMptb7kjCUuCjjQRN2Mzj/DbLRGk+5aqLQBcbs6tlkUYHQ4pcpf01iGZhAwTRSYIUIQ1ai45UHwuvZwwl6bJQN5yc1wQOS0Q9bQzrj5TtDOol3uVnc6dsfVs8bWT21bRgoSAP sBDSK3jD 6DKLw87TnQVvz6HoMc76LeuinrKYBvveBtFCzZR/lWgZ6cKnvxalhYNJ2FGqgiFwJ8RO3/5mb5M81MueGd+VMEdIYZoD680dhNTIosEaOUhwm8nl82oG3QbvFRd+kYmny2oHYEwVu3QkyrrPUn/JvUIiHEQ/8HN35Mb4i6duSPIdzfuFbCV5wkDL8W+bKA86Qa4d37ybIelDrd39yBXs2xM7IoUAG8OC+C2fD7HGJhIGFm4NEwq39C4Ish6bspauBMNHhKa6RgB3+SgfDzXvJYXgts6AKIXB0fPAQUN/uHfwuQoaBo7srfXqts9O1qzVZKzbKS3kO1b43nx5/c4Px4wMV/nsxjEYr2oq+7EY3AqT3HxULJuP9Hjz5Ow== 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 8:05 AM Matthew Wilcox wrote: > > On Thu, Feb 16, 2023 at 06:14:59PM -0800, 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. > > How often does userspace call mmap() and then _never_ fault on it? > I appreciate that userspace might mmap() gigabytes of address space and > then only end up using a small amount of it, so populating it lazily > makes sense. But creating a region and never faulting on it? The only > use-case I can think of is loading shared libraries: > > openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 > (...) > mmap(NULL, 1970000, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f0ce612e000 > mmap(0x7f0ce6154000, 1396736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7f0ce6154000 > mmap(0x7f0ce62a9000, 339968, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17b000) = 0x7f0ce62a9000 > mmap(0x7f0ce62fc000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ce000) = 0x7f0ce62fc000 > mmap(0x7f0ce6302000, 53072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f0ce6302000 > > but that's a file-backed VMA, not an anon VMA. Might the case of dup_mmap() while forking be the reason why a VMA in the child process might be never used while parent uses it (or visa versa)? Again, I'm not sure this is the reason but I can find no other good explanation.