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 38EC1EB64D9 for ; Tue, 4 Jul 2023 19:12:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 973252800B0; Tue, 4 Jul 2023 15:12:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 922A8280096; Tue, 4 Jul 2023 15:12:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C3032800B0; Tue, 4 Jul 2023 15:12:09 -0400 (EDT) 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 6CF36280096 for ; Tue, 4 Jul 2023 15:12:09 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 30F1B403AF for ; Tue, 4 Jul 2023 19:12:09 +0000 (UTC) X-FDA: 80974874778.14.D418623 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf27.hostedemail.com (Postfix) with ESMTP id 50A3340010 for ; Tue, 4 Jul 2023 19:12:07 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=xky6LG48; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688497927; a=rsa-sha256; cv=none; b=aYNaAmHle4IKYwfkKrUk8KPHZ75en5vIrrgSWvdhapwtYJgYrpbmVKNR9XmVRHpaDjS62P taYYxvf4Lei2aCDRSHX7ysA5b/mWtX+qZuyRLTT0W9/QTucu66RNybpZC+AVXRD7j15hqJ HB2q2gJ4sQWEzAOTeN4Y7uclPaMphbk= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=xky6LG48; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of surenb@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688497927; 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=8ecsofM/6SubxLPXGzwEdQxZAxN8kj7S/eJGu9HRSAQ=; b=eOYx9azlb142QDD0e0Gql/F9ARlbEgnqGaK6adI9rnFiN6k5k9tUQ/I21bB1wENRyEOJFa XmCENMX1h8wiA0raB1zfsqmhIw6lyzhSBfuvUXm+N0lO9gswZIDBsD3HPAYXZ0yv5wk2EZ DWp4WQZYa4hplWn2DpZyug78X8x4hZI= Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-577497ec6c6so49923707b3.2 for ; Tue, 04 Jul 2023 12:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688497926; x=1691089926; 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=8ecsofM/6SubxLPXGzwEdQxZAxN8kj7S/eJGu9HRSAQ=; b=xky6LG48jwyqr4+GyiACqfWMfG8fCTqpPyhcpJzGqx7X8me8SLyuRX8NME2VjpzIiz ZnRSDBsdbvwQXALV7kwxRy5MdZFhs9mmqmXzhCcFo74os6G9orMTaP9+3hAO4cfc9CKT ghM73EmIdyWhkX4a/24l0qvNHbDnSo30MVVRm5Tc+P82a9xH7jpFIR8jNTUhbFesw2bG IvpklRD+6bZB1g21BsgKpqOYIP4aJQlKlEH0eghzik15N46JNHPqFRa943OnSR8NJpOn 7u+AWRGniF7yRUvWyZCwqRWfwmeldjcH+qFBW0bA83sH1R3utoT3JAA79hYJYHYdhzi1 WA3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688497926; x=1691089926; 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=8ecsofM/6SubxLPXGzwEdQxZAxN8kj7S/eJGu9HRSAQ=; b=KmQ/tVUxDEvDxJSZodMq6gPVWlUemN8Up53CYVWH85FOeSluX0kOsYTTTB+FuaDP6i NE5Qz/v4I0xoyCwxgM5rcQOSDsz/zX8Vw0/dZUt3n8s46RzHFUZnuGk5wNSol3HZjtX+ myjbXcLOch7IOtWZv8/0VqWHqxLyC1CdNKjek06f32QuUCXaSmK3FAN4XPe/A9CKyyPL LhRCH9dxKqWg3fPn39/+yJivjsrOA723OQCL/SaHu/R6lrPJWCkADDSlgBlRR2nhvOnN 6DDKefzO8CV4F3hGMbUx0NdDN+wxm9dOrCBYhalYSrxihPfkU/nxyf75Z5FLwaRIOnOT IfNw== X-Gm-Message-State: ABy/qLbvNnobThekIfDNffC8WTqbC6xHWE+Q1Prlj1Rq9oTk43RVXU8b eOZBoHMKkiHy0iNysesqUh5WIsFW7cbZCGmR7I9+zg== X-Google-Smtp-Source: APBJJlHVWBomM1nlME28m1F5SSScObRZzTRspZFiOF2KtN9M4K/R87ncz2/cuLNR3YAAsNzPp5tAJiP842IigRvd7NA= X-Received: by 2002:a0d:e6c5:0:b0:570:85b2:e6dd with SMTP id p188-20020a0de6c5000000b0057085b2e6ddmr13540666ywe.17.1688497926184; Tue, 04 Jul 2023 12:12:06 -0700 (PDT) MIME-Version: 1.0 References: <20230703182150.2193578-1-surenb@google.com> <7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com> <2efa2c89-3765-721d-2c3c-00590054aa5b@redhat.com> <3c042dcd-192e-7050-07f1-ce891b95dfca@redhat.com> In-Reply-To: <3c042dcd-192e-7050-07f1-ce891b95dfca@redhat.com> From: Suren Baghdasaryan Date: Tue, 4 Jul 2023 12:11:54 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: disable CONFIG_PER_VMA_LOCK by default until its fixed To: David Hildenbrand Cc: Matthew Wilcox , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 50A3340010 X-Stat-Signature: npst5s45iiakcochtfaump3u6jcwtpta X-HE-Tag: 1688497927-765250 X-HE-Meta: U2FsdGVkX19B4J+ngntU/reCVSXD7MvgAswHvW17b9WbVToDEjaSkplEuImlwEI0bymEY1lcr/GPVEkCuBb6Y0e8iGTEN88qNt5LcrU03Pu2ggxc9Xt1XN/kvdUVPC0jpbo2/7jn5ZtIWvFsWhv8haBIeXKsSZtfud/UrD5iMKW1JHcxWVXshbQepepiqrP7p3g5qDVfXv5khMahcaUNc/h5bFD32+ki0AJGi6HcsETdc8FGcGLyZUGeQtyKlMYD/WIilA1aHT+HjoHdrage38LzZFzua937QOBJlvN/8+1jfS+lBJgcKYcQPYXYuL8otdM5PkYtK12pB1aVd8o6uwRJTafrb0wFF8YfQrNMJXr9oiZGvz8/evznJ9PWSDlhy1dS92Ip+/j7TyLI0x/lD6mxYKzvAGxJL3DoPl8vQBvj47TbQrvF2ckWoICWLGjwtDGRYJVHap9JtW9V8FQ9VPO1Q/I7CzSXE5Xfib1ct0Fc+Fra3jzx4dcKSVpXOPm74DmVB/omJiRe9nL62TD/wW8DUduYZecGbC0O8YLtUWr2l0iDuNEgYUj4DimgHA07ndmbPTkeDW13LevgxcuoER48uMEl0znV075+hHX92//DbyesR8blgvqyhmALebgcilwhOArXflTLEf7BKfWzeF+gXSpo6pAqLn+GOo1Yr9CvKndBhxjiiKR2BCu6PZZii7WJp2YV4vcxL8QzUG9FitF1JHzqfIr2wGtgmPJi7Uu/oEoD47uuGJPhEuc/NvTGw6H7HNAwzjrMdWDWppzPHluk3EMjWwHIY6Pnfq/ep0qSS0j19PeDmMRyNFLzfjSZyq1httOhhD+9ppqcJKf0p4NQQDM/ltB3L9SGyIz4abslwP50dvOG4tJKkgIx9FB2HKxswaIBM6RYx8uzHrRFsAKbKvsiCydnzL5VQ3bu9TeUwARP5tuEW67xW45JCi1aJC1s8Tt4cZ/QESiyjtf XMiOyCju eAR7mq0dsbWE0JpVsAwL//iG1cVrQoYmw4iKwx6DtRrhZu2elAibkOZw1BhGCVen0f5smt4y6ObX592BqHft/ISX1OS8SRpXztkOD0RldgCKmmIRkttpHcv1mKBBMZ2r0A2D8vOwsuc8YFJs+Z1f0STQKxIIqv0m2ddHgvopaL8a8V+J0MDROkqVjrI8Wvws2Z1NECBmR1FO/imq2+DS1xjmM0GroDnAXRh7sS7dycE76Y6yQ92MurAsD13XiA95/72pdcxuI5AjwSerg5g85+Pd2HAxBA8OoQvztwwJjeSsV4W/CEAwQ9+3Ad7fWS4a92ah7X/GPXP1EEXmyb8u5bRTFWTsnWgDSQeGKOER9PewHXSZtaGlOvLrNtgUpov8oFfoXgXOEdI8NZrKWn96P9JL7prEZ/E/pN1azguSAvY+g/OapmK0JaL4QiiVgg5eodEJNzG2k5JRWW1+YZGbrgB2w7L6TgKbOcIZWJuWKtzTsvYg= 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 4, 2023 at 11:05=E2=80=AFAM David Hildenbrand wrote: > > On 04.07.23 19:56, Suren Baghdasaryan wrote: > > On Tue, Jul 4, 2023 at 10:36=E2=80=AFAM David Hildenbrand wrote: > >> > >> On 04.07.23 19:21, Suren Baghdasaryan wrote: > >>> On Tue, Jul 4, 2023 at 6:07=E2=80=AFAM Matthew Wilcox wrote: > >>>> > >>>> On Tue, Jul 04, 2023 at 09:18:18AM +0200, David Hildenbrand wrote: > >>>>>> At least the reproducer at > >>>>>> https://bugzilla.kernel.org/show_bug.cgi?id=3D217624 is working no= w. But > >>>>>> I wonder if that's the best way to fix this. It's surely simple bu= t > >>>>>> locking every VMA is not free and doing that on every fork might > >>>>>> regress performance. > >>>>> > >>>>> > >>>>> That would mean that we can possibly still get page faults concurre= nt to > >>>>> fork(), on the yet unprocessed part. While that fixes the issue at = hand, I > >>>>> cannot reliably tell if this doesn't mess with some other fork() co= rner > >>>>> case. > >>>>> > >>>>> I'd suggest write-locking all VMAs upfront, before doing any kind o= f fork-mm > >>>>> operation. Just like the old code did. See below. > >>>> > >>>> 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. > >> > >> Well, the design decision that CONFIG_PER_VMA_LOCK made for now to mak= e > >> page faults fast and to make blocking any page faults from happening t= o > >> be slower (unless there is some easy way that's already built in). > >> > >> So it wouldn't surprise me if it might affect performance a bit, but > >> it's to be quantified if it really matters in comparison to all the pa= ge > >> table copying and other stuff we do during fork. > >> > >> Maybe that can be optimized/sped up later. But for now we should fix > >> this the straightforward way. That fix will be (and has to be) a NOP f= or > >> !CONFIG_PER_VMA_LOCK, so that one won't be affected. > >> > >> Maybe this patch in an adjusted form would still make sense (also to b= e > >> backported), to keep the feature inactive as default until it stabiliz= ed > >> a bit more. > > > > Ok, IIUC your suggestion is to use VMA-lock-on-fork fix even if the > > fork() regresses and keep CONFIG_PER_VMA_LOCK disabled by default > > until it's more stable. That sounds good to me. With that fix, do we > > still need to add the BROKEN dependency? I'm guessing it would be > > safer to disable for sure. > > With this fixed, I don't think we need a BROKEN dependency. > > I'll let you decide if you want to keep it enabled as default, I'd > rather disable it for one release and enable it as default later. > > Happy so learn if taking all VMA locks without any contention causes a > lot of harm. Ok, average kernel compilation time almost did not change - 0.3% which is well within noise levels. My fork test which mmaps 10000 unmergeable vmas and does 5000 forks in a tight loop shows regression of about 5%. The test was specifically designed to reveal this regression. This does not seem too much to me considering that it's unlikely some program would issue 5000 forks. So, I think the numbers are not bad and I'll prepare the patch to add VMA locking but will not add BROKEN dependency just yet. If someone is using an old .config, they probably won't notice the regression and if they do, the only thing they have to do is to disable CONFIG_PER_VMA_LOCK. Of course if we still get reports about memory corruption then I'll add the BROKEN dependency to disable the feature even for old .configs. Let me know if that plan does not work for some reason. Thanks, Suren. > > -- > Cheers, > > David / dhildenb >