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 14730EB64DD for ; Tue, 4 Jul 2023 17:56:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 880EA2800A5; Tue, 4 Jul 2023 13:56:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 85841280096; Tue, 4 Jul 2023 13:56:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 71E662800A5; Tue, 4 Jul 2023 13:56:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 65110280096 for ; Tue, 4 Jul 2023 13:56:36 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3ABAC1C7E04 for ; Tue, 4 Jul 2023 17:56:36 +0000 (UTC) X-FDA: 80974684392.11.9EC93FE Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf12.hostedemail.com (Postfix) with ESMTP id 27C8440002 for ; Tue, 4 Jul 2023 17:56:33 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=W+PG7xGT; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688493394; 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=5IrtjPo+A6JbAq+di5c2gfe+a2CAyxet4us8TTLra74=; b=lrTcA3++YboDh1FKo4oL1iNQzuidcQilcGJ5re602N9UdLXjO4AQHjxzUw8fKFTWfKNAuO 4oa8DiD6Ok+AdCuv1FMcegwEXe5WoEdNaLfojk1mmf+4pYNTG0PiiWrwefHqOwx1JL5TEz NtRWMe/0yhKwlGNVc+iLKnWbgLbQgmU= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=W+PG7xGT; spf=none (imf12.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688493394; a=rsa-sha256; cv=none; b=Codsqq9HUJ+uxJdAtnIkKUvhBfBs2GinWHOUFdLt3z/skMKA1l3f19BPUYai9exx1UvuCy x4A3Ew5cd4xvvnwcQkSrtbY07rwooGWGA7ezta/eB/S+pfi+M6HYP0AxEEfFuFJlhHmxGp q1cfJ83XutkyyZMbKSwP0WUMPbK6ytc= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=5IrtjPo+A6JbAq+di5c2gfe+a2CAyxet4us8TTLra74=; b=W+PG7xGTtWSwuwOLbCzalXHFW2 gxH86zuhYSsqjkdt98+K/h2XVpGX3E3CQEpvA1mrt2hlcYw8b5AMIkcZdYneHTbF+SmywfirTuooy DCmgX86OBIuy97M9f1A9yaBIKqp330hGDVFipKtAjDZPljDBfyH1mmFSIAR8quer3RFkHjlq4jExc Z/COPUYY2rZdZUG7y/tRPiQuKKL88uXXbEodo7BC+AkPAmYMHq1GFSFk5ZLxlSYXRH1InOz3fRSU3 nDu0xwQR7I4QW858BvjMnQHnqo2yvpOc7OESRwbnvJDMFNZ1d/UolFepFG+xdMLX3UHv8TkHWI8Yx Vh55daQQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qGkFd-009Luf-VW; Tue, 04 Jul 2023 17:55:46 +0000 Date: Tue, 4 Jul 2023 18:55:45 +0100 From: Matthew Wilcox To: Suren Baghdasaryan Cc: David Hildenbrand , akpm@linux-foundation.org, jirislaby@kernel.org, jacobly.alt@gmail.com, holger@applied-asynchrony.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, peterx@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, linux-mm@kvack.org Subject: Re: [PATCH 1/1] mm: disable CONFIG_PER_VMA_LOCK by default until its fixed Message-ID: References: <20230703182150.2193578-1-surenb@google.com> <7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 27C8440002 X-Rspam-User: X-Stat-Signature: 58j8ay7o8szccox53whoyd8s7o1mummj X-Rspamd-Server: rspam01 X-HE-Tag: 1688493393-694179 X-HE-Meta: U2FsdGVkX193JrBxIxPTmdtLdDLf8slW9qATaU8PXxHiFEKkGX/AAXh0O+rEV3SAjsqgKJijpbgek1jTWA8voC9a+Dzo8Gve9ZZKZcysxYQBRYtCptheznFtgjas0koI7BQ6uvh7lCeebEIQW1+NOBjm6oz93ya9T4XTqa1gpcgiM92n6L0ou1b9MsjF91zNNKMZojirJnLa5+tAgV1zbkLYTyM/yBEFgkmYnOGsghv/a100a46Fr6N6dglJryiJXzfK1sEvlqZmgFF+UcvoVnyP/NQ/mswPDDkEjdKzR2m1+LjJai59zhTkQLNtDVAHmn0Kgp4G8izPeyDx65DD17PIjBb6LP7M1TzTM9ffxTTJNGLhIHgBbIhsiBbb6EwATuKhuMYhSh2ysh7J+VsgC4PVPhDsHAM2/MLHNI4Er4KxjRwt/oc0Qzw5rW3qGzpBY9ByA/pqx9DL2V7kwGD98Yw7Uh+BiGjodsp2U86Lbdn7vzyMJKrGSF/Hshp01Z1t+Z+GiXeUkIisK/xZmZiP2ecccNID10EsW+1qE91wQ4K8DK7S53Or/vu/jjAE4gR6di27T4lH0w1IYReSfxBAmWpf30SGQ6QpKsSUx+s9TjoLv/L35roCNpDm6/Ugo0uqrC8Ez4Qn7Akcx7ZsvxA7gsxyXHHb80D4SX/nI8SjjfRv5GwcorniRDi/pItnjB0ZnmZy5WgaL9iaJ7BQKVaZ/R+W7Bp0BoSZ1V0AWPgQR4G5Wt5koWv1Y/ukwUGiPdahacRWdnHCcdwXCCDs3Ug6hnHBui+E0rcRr7/ekuPYRL6wiigy/IqztVXyJHik2yyDN+ePGyFAkoLvx9oEaAm0sr8Vfl8m2U8wcYTJgxTQaKjGLNzXbTnpwEnGRM4cQ56/JQ2oT8nkwBnLT0CC/2dA7suPR9WcISkHBoUq6imfDtCaly4j65PrCSdwxgxscm7QoBXRBCiXz5+iuXBUEwn MLmFHt6Q IA9IFuJz6q2FN6uZ0mxY+fMI8S480+B6TjMnURCocP+oOmZjfo6WV88KWd+/1oci+QWlQl1pfdPuO4AiJH9w2pbsqwWfmzQxMOK90kXaRASSFVn4q8/J0dGIFCa2Q/qy9Lxl49DTqAGAIcs4lyEaFg1FcBfCiXxEGr1acR1drGEKxF8BFR+ZTyFI3a9C1Z8wCStkGNm1klZ80fm+mbLJ9eT6KAU2GiCFjTClt9vil/JZ/vwENLkqaz3xqZH/4P3X62NKEfqc55Ia7jqCaCk/QQJkButYMqr37hSGqEZ/X1YbwqzEoZa8V494lrh2iCMjgKjIY 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 Tue, Jul 04, 2023 at 10:21:12AM -0700, Suren Baghdasaryan wrote: > On Tue, Jul 4, 2023 at 6:07 AM Matthew Wilcox wrote: > > Calling fork() from a multi-threaded program is fraught with danger. > > It's a rare thing to do, and we don't need to optimise for it. It > > does, of course, need to not crash. But we can slow it down as much as > > we want to. Slowing down single-threaded programs calling fork is > > much less acceptable. > > Hmm. Would you suggest we use different approaches for multi-threaded > vs single-threaded programs? > I think locking VMAs while forking a process which has lots of VMAs > will regress by some amount (we are adding non-zero work). The > question is if that's acceptable or we have to implement something > different. I verified that solution fixes the issue shown by the > reproducer, now I'm trying to quantify this fork performance > regression I suspect we will introduce. It might make sense to do that. Personally, I'd try to quantify it with a make -jN build of the kernel. That workload is fork-heavy of single threaded processes, and if it doesn't show much difference, I think we're good.