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 6401DEB64DA for ; Wed, 5 Jul 2023 21:54:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9FE0D8D0002; Wed, 5 Jul 2023 17:54:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9870F8D0001; Wed, 5 Jul 2023 17:54:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 827A68D0002; Wed, 5 Jul 2023 17:54:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6F8BC8D0001 for ; Wed, 5 Jul 2023 17:54:55 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3EA59B0386 for ; Wed, 5 Jul 2023 21:54:55 +0000 (UTC) X-FDA: 80978913750.15.48D2345 Received: from mail-yb1-f176.google.com (mail-yb1-f176.google.com [209.85.219.176]) by imf08.hostedemail.com (Postfix) with ESMTP id 4DD40160017 for ; Wed, 5 Jul 2023 21:54:53 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=OzVmM+rg; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 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=1688594093; 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=/lEjeaJKV9LlXi1k1z02f2PJIzF7WHFogLjflvF0PeI=; b=jrJ1hAe/xcS93S63Q24EXr/3IOtag3TOVDloiv4O4+C2ON5rD/l/LBMhtP6yp0pK528Ne2 rmYDPh9d2hsvNtZvpObi9Tvn8Sd4DB1Av8EyKUQnh+rpvkSr6nzu3gNnjCaz97tZghmqiB DB2zRx0DAEtjB+5HscL+DyJravOutVU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=OzVmM+rg; spf=pass (imf08.hostedemail.com: domain of surenb@google.com designates 209.85.219.176 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=1688594093; a=rsa-sha256; cv=none; b=flCdF/Jkyy5FTTUnsJJow7N+CA2X0rTXFIMptk9dXjw/pit6zS1ECfIjkewERzynDDCVJa PieWeraWBb9uJ8vpkQeEKi2V6jwdjQLeM/KCob8pNNHitcyBozXYXEp6JejIxQ1KQU1dTj CDiEM6jaViWE7rO8GLkls2Ux6xI8ys4= Received: by mail-yb1-f176.google.com with SMTP id 3f1490d57ef6-bfe6ea01ff5so8048784276.3 for ; Wed, 05 Jul 2023 14:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688594092; x=1691186092; 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=/lEjeaJKV9LlXi1k1z02f2PJIzF7WHFogLjflvF0PeI=; b=OzVmM+rgHvkIoKrmM08c+GV2eEikQ6FIM7iy2jKO8PH7pcVoImd0XlY3faSJLXojFv iLS42b4kIjjLm2BU4F8gXCdpuYbmEPsLARtnsClM0Ep0lluoP02lpL2S+tO+eQlScEiP aBldBZGbyQrqWks0bkIDM/rjVaTYCOKPc7iVv0wjNC5wXYTL7yFMNHA1j6y+pvxEEmBS Cle4mtGoUBYfERWdq12DdKYKDpCGNTf8UBOag8XAvH+NFJVJ4+wfWd4fIV9/GaONBliv WkjP4MoRX4XsFFDDejMNuSccEbFON/xdjyWoNzvSNSJWWMhLYWJBCViYRaI90qN/KZ4A ZMmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688594092; x=1691186092; 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=/lEjeaJKV9LlXi1k1z02f2PJIzF7WHFogLjflvF0PeI=; b=LKM0Wom8Y/0CtisXdlYFUyNyA5qA7M1Dw05vnlLXg8t2sEEeLps8NZPl+YxhpMxvS1 UUJB0yoQBSkvpBc8OFZvOrNwrjN+ngarutHa7xkYJIIOs91y625Pa7sE+HQVYQ+Wg/mt sdJ7/1noKLy19gs/s7f1mN+XSux8QS749YK13VZTS6Uue2/i3ZYvdJh2q3/AM9tbv3oS vwpQLXh3j+8oY7YucikRxyi1R41iyv7mOvYW1qpntUuwFdK9djI3uMw15ysPDy8NrrR4 qyRC0lT3T7CSsO+ZmdcjnkiVWx3+ZPpgbEQ8Z9t1HbKBKSqA8tWv35wehecJoqDGviTO OqoA== X-Gm-Message-State: ABy/qLaGMqRBEH5fSaSGr/SuUzmvhfDl/ld9LHysY5YC1jXpf0SWzLCW K2fhyH9QvXMDK4rfYDE1lHdpaaw3xC/SsIity0THRA== X-Google-Smtp-Source: APBJJlG3pO/OUr9ZM4kywYL83J7aI9+LAADDvCgM6kcDjGtYf7/JKrgsRE+xlLjjN76P0+cP01PZykYcWRl09YUhZ84= X-Received: by 2002:a25:ea43:0:b0:c5d:c5c2:b46d with SMTP id o3-20020a25ea43000000b00c5dc5c2b46dmr123430ybe.55.1688594090753; Wed, 05 Jul 2023 14:54:50 -0700 (PDT) MIME-Version: 1.0 References: <20230705171213.2843068-1-surenb@google.com> <20230705171213.2843068-3-surenb@google.com> <3cdaa7d4-1293-3806-05ce-6b7fc4382458@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 5 Jul 2023 14:54:39 -0700 Message-ID: Subject: Re: [PATCH v3 2/2] mm: disable CONFIG_PER_VMA_LOCK until its fixed To: Matthew Wilcox Cc: Peter Xu , David Hildenbrand , akpm@linux-foundation.org, jirislaby@kernel.org, jacobly.alt@gmail.com, holger@applied-asynchrony.com, hdegoede@redhat.com, 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, 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, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4DD40160017 X-Rspam-User: X-Stat-Signature: 5rgm4ofyr63kjhyopeg8wg8c9ytux7w4 X-Rspamd-Server: rspam01 X-HE-Tag: 1688594093-331863 X-HE-Meta: U2FsdGVkX185QwaNX5VVzYzY4NasZ3GL097dA3bl87225FP6UcmOEOnxYEbJ1/QIXZF5y66CUqNXMJCwL/LCQ9P5P2Iq/CCncp8qMyX/390HgaYxIC/H0FrS/NvxLt/W8yM5skhDQbin7wifQxYQrKysR73L5MXKuJhmYNdn28ld/4ZBnOOXznKc+gfecPieWYUW8XcJALWV9nLvccZ8PxnZjs6dFUNzDjoXYLrTaVgQWRoLH4/YcrxoXiMyj9/jmOeadvNNraTI38gkNUndc2UrjpaQJnkd0lWv4oX717eA+lP0J+NWJexU+u32hoHmQ8QSKEVewA+QeWsDeHJnSDODdW9Be0XIV1DM5p7Gj4/nyacdPg6aUfQ7lfXZSkYZzCw82YFIKayb8XmA609oRBgl31FCSwAjgRBP8Oe5c0EkQly/DF/cb6GhKg/G9YOYoiYCJxa448ntWRlVjzkEm/CX37xD5YOC53gXfWS4bz4j+pIwAP4827GMjRb4yQbYiXHWMYM4QwfjrCxaCpDgNTTO/xoFdbKE7NZwQwi2uCZUTchdCKcxcncuxHDojB1DjN4j98lkVT3EDv+3aP6NdKjqtam5w2GPmp5dgzZmtrUt9EqCVepkqAfvaFPMB1gTrEYy6iSoEws2Y9VKcj9fNOwREEgmzm+gH6co/R236JQ9/pu3OYeSODblpdwU/qHQVJLoIZlsYl16guXAUGCkyGC2rLKc2d08+8kE3eP4vGUWU3HM8l+QMnuhTOkr6Acr4K0uJqiO2tSJ6ZoJ5ZsU/Fst3Scydrt50tdbMGrRFVb42AIy0UsgLJy2MqsEw178J3DRfMMoWUDdKMkvqMwpJwhRiXWPGv8GVG40cwegdmCzDObfQIVlD9H78VT247zP+9tUP6nH71s4FLWeKaVScL9PiC2M6hm5V+klgEshHLNwYHbX52die3NMcNkXEHest8YREwc02aAanvhU69n bqVq+UUG zXanYaXSYs7kjUWTNoAf4h7zhYUrycSJslsGmhHaecTEIyGy6JE5i8aqbFXoXHXktgdgn/4uBPEU2RD1g/NZapWASd7qHgXRBkeRxfx81gb2UMHu24Okr+wHMwwpGsJil3DB+tBZnoJjh7/WRaQHgkEx8XgYtT1LBITNdnWf/7c3IbVCP6XA4WodydjP0Qul1CMo6ZYQdPX6QjdvGB7s5FeEFk+cjkdd+yZhWWWvhSx//rIdGWCJnpiO1uERTPv8EWtVIlPNm/41AgcDF8+/jqwdb6eL0ntu8IQX1RKeFL4Kfq6MPDxlTcfS570TU1GXomlFWJl94V4t1xltG9Mx2/Zk152JkWEFuJFQDKIDey6mGXHljLWX8Tc8YixV5ecU2MyCyk8tRbfZ03PoqgNvi/9uhGw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000022, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Jul 5, 2023 at 2:28=E2=80=AFPM Matthew Wilcox = wrote: > > On Wed, Jul 05, 2023 at 04:25:21PM -0400, Peter Xu wrote: > > There'll still try to be a final fix, am I right? As IIRC allowing pag= e > > faults during fork() is one of the major goals of vma lock. > > Good grief, no. Why would we want to optimise something that happens > so rarely? The goal is, as usual, more performance. Satisfying page > faults while mmap()/munmap()/mprotect() are happening is worthwhile. > Those happen a lot more than fork(). > > In this case though, there's also a priority-inversion problem that > we're trying to solve where process A (high priority) calls mmap() while > process B (low priority) is reading /proc/$pid/smaps and now (because > rwsems are fair), none of process A's other threads can satisy any page > faults until process B is scheduled. > > Where on earth did you get the idea that we cared even a little bit > about the performance of page fault during fork()? I think the original reasoning for Android to improve app launch time could have made that impression. However the speed up there comes not from allowing page faults into the parent process (Zygote) while it forks a child but rather from the child being able to fault pages and establish its mappings concurrently.