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 ED05BC0015E for ; Wed, 5 Jul 2023 21:29:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3EDE98D0002; Wed, 5 Jul 2023 17:29:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 39D4E8D0001; Wed, 5 Jul 2023 17:29:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 265618D0002; Wed, 5 Jul 2023 17:29:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 167838D0001 for ; Wed, 5 Jul 2023 17:29:08 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id BF1CE1A0484 for ; Wed, 5 Jul 2023 21:29:07 +0000 (UTC) X-FDA: 80978848734.12.9565452 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 8513DC001F for ; Wed, 5 Jul 2023 21:29:05 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=JQSE5WDO; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688592546; 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=cgSmgMJRLpJHBRFXoz8XxIGxxvj9mwwGxUoWKCRz164=; b=7wrV5NU5j5zuQYT4tUaSKdnD5fI/sPJMWDMv7B/ompzlzz1kZiSzZYgofIDAtjCDGuoiRO dP6Tc8vgD/eKE+jXGHPKSXlh8Knp6XUiWYMbaJTQIWdRrdCeeFhvoTNdDvLuyseBih6BlI vRkBZCBp3w2sjxff3i3lOL8uBKwXGls= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=JQSE5WDO; dmarc=none; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688592546; a=rsa-sha256; cv=none; b=L1P2ZCCk+h5BoFwJ0Pwi/wCIi06pG0Z5fmfgLuDlYP+b5kg1QlZz2ADX/75+JTMbX6GDC/ Sv/EdHAKW57MBgrnt6sgfZLeqvJ18IpVMxGxzYVjyh9q4S+dEos0uGVx+fWxM6N04CX25s NfBUsc51DCfgWXQpqiL9aj1IO9w0wv8= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=cgSmgMJRLpJHBRFXoz8XxIGxxvj9mwwGxUoWKCRz164=; b=JQSE5WDOUg+gd658BVvKQIfUJx 7+D9YjlvW/5ZdTkkdlgIZC9IGZPyKyRHXjjOb8q/jh5PmElpP+i3F9XT41LmI11uzY1s8TvsrVSrm z3uM3r5sbTJ4cM5ZRnNkkZGx6v0W/gRkeUqED2U7YOs9tImfsNX54mawLDAXpsjDTSzXdKv8Z/x7m 2xLdDpqpRys0F5YliCsoIA51JpPo1NBbtwuHvv+Y7tGGarmBBGMA1XN+U3b/kWOZLCdLZrgHoBr2F JHYxA6l//VaGn4uU7dk2N2KmByd3hmLW/vFq2OqrXzxTyJpGMFQAiqi4pL5gDbK074CzFLXzMgcFu 0v6eLb1g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qHA2W-00ARLH-7a; Wed, 05 Jul 2023 21:27:56 +0000 Date: Wed, 5 Jul 2023 22:27:56 +0100 From: Matthew Wilcox To: Peter Xu Cc: Suren Baghdasaryan , 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 Subject: Re: [PATCH v3 2/2] mm: disable CONFIG_PER_VMA_LOCK until its fixed Message-ID: References: <20230705171213.2843068-1-surenb@google.com> <20230705171213.2843068-3-surenb@google.com> <3cdaa7d4-1293-3806-05ce-6b7fc4382458@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 8513DC001F X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: oqe8ow9nn6qgw819cf4okfhuojbew597 X-HE-Tag: 1688592545-281416 X-HE-Meta: U2FsdGVkX18fEp41DUWDlw8xaz8HP703CQgFsVraRo+DNol2H3ZMpq8uNiIz0EFDBXLGpwHzOi2SjqPr6dcjnkCz4NByBOnO6ZfxWCVHrxn5vqd16TUXt9rEX3Y5HJXKMm56DFO+wLq/qGphVuGkySZNvPa7peUtqOUBsDS4M1gRFw5PokvfgK/0Nw5e+xDSZ+UnMyRhmgh8v31mv3ScriawYHSG7IhvdmreMBjIMstbAqajqLnTqqFlk+LiA06lx9Sp2gMJjzmAWZ71faz76nqtXVKSwvYwtsWpqsEb0dtVcK+dL/++yXMKzoBEr8We8fFwFtR7p+Yr/34uOoxWK8bh8PAMaratn6lPvjKD/0iBkeW11sxvimoMry4lK7hmzOTwU/XBJkZsBQzQCiNB+yE9s1SIq4iehrTDY7nSWFWotb9QkkCSU+o5NgdsTpoWmnznxowUiCV/ViXaEWv1YbuZAcapMar1o+w29zEjRSWey4iBsqn9XGhiQaDcvU+XhrlxHLjFGh9l8yd9BNFm2Rq9/8uh16r+l70/aUcHE2ZKYDQAEVixuhN+i5P9k+xWH6z87LN9Q/k69ihdrybu214aDvraq7MadPwysJPXOH4TKRxT29QtDhQ4eq4SHuzPk+UCXtZxpCT+bIho3PRLeDk/TiRtBDk8ZU1H+X5Gqv5pnRYTYqIBqXufyiG17+C6MofJBHDuRaQS5R1KaNdTe07hovQrwq4JfD7vQgUmEmTl2RxRrUiw03rGvPyuTvvR/86TKX/w3+zkvbYx3TGkek5v6W+rUQE8lekyjW7KtlTa8t/4rzfrbRwyq4qn/BZR4sO+Vfp9E3wdLLef7o49Uus5MbzygaXBRsxchixEyg6YdG8+/uWiFHeoSedu/VLmJH4CSqchahbYLcEiwJqEi6xu8W+cTnrcNXfmyD6C48bYb7cfg7tg14zVzFGEot3pKOeV8oaKUgdTkmmX8Ap YjW7Tpnu 4eo04fYagvODGiEInURr+L06g+yCE0FmpWd3CAvh6+Tg12XrgXFZrxEYejxWp5Ch13XwFMfwNSsmfsXGEqJtNLnEQxG/NpGnJ5GUatUhp1Dsfp/J6QVtblEwtzNmnYr4Afi/1uIeBqRREY/jmQOddoENXrCnQxqpTa+BAfYasnTTqYN1tpUxo661gKkEenqY3jgEZmltkGq3ZSlFwvGfmmQ86W/3Zw2tmsq7Wg1w1oEgERI3GlmkvowRjGW8WHdD8hmtU 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 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 page > 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()?