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 E4DACEB64D9 for ; Tue, 4 Jul 2023 17:56:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 439DD2800A4; Tue, 4 Jul 2023 13:56:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3EA89280096; Tue, 4 Jul 2023 13:56:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B19F2800A4; Tue, 4 Jul 2023 13:56:34 -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 1D74D280096 for ; Tue, 4 Jul 2023 13:56:34 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C550BC03D0 for ; Tue, 4 Jul 2023 17:56:33 +0000 (UTC) X-FDA: 80974684266.02.E9C5464 Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf02.hostedemail.com (Postfix) with ESMTP id 071DA80011 for ; Tue, 4 Jul 2023 17:56:31 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=aHJSEXAg; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.219.182 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=1688493392; 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=VF3Qnv/fRo6auQhDr6SI8MJNl+7FJb8MLAYLmOcNyIU=; b=TfFRQg9GYdofLid7VkmxWkTrcRTWwirfl6tkO0bgDTk43Uki9JujuRC2lgVUNTGRsGLOPh DrbV0H5PG1Xi5dt9NwsqBTSwFaNSwNgkbnD+d0rbNzTYd+PNIfJkHN2unYwrMUNb/fXYgI xZH8j4gYTBhV6XPphkPS6INd0Up29uw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688493392; a=rsa-sha256; cv=none; b=LaANcvoD6h2feu0VKN1IBC1AsO0V+esB9pGV8AZGZVxou2jR7hxx5tcWfp7/atyP8/fdx4 F4kLFRWgzHXkSJxTrQXYFWB6HTiPkOQsgQyn3We395adDzgvv9wsgeWtxwkLc68ZvprTdf fxSvDOCnycp1cL4T7Cxbw0t7fF7Unxw= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=aHJSEXAg; spf=pass (imf02.hostedemail.com: domain of surenb@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-c5e67d75e0cso773332276.2 for ; Tue, 04 Jul 2023 10:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688493391; x=1691085391; 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=VF3Qnv/fRo6auQhDr6SI8MJNl+7FJb8MLAYLmOcNyIU=; b=aHJSEXAgBdji4r1xdX40kIgy+yPe08XisH/jfI8hFO3UIVrAxaOtsxrmLNjT0/2m+Q wZwqkI+PoysHUjxe06h80EGPPOxEuJJSE8Rgy8454Sg3sLUtTn3hy4Jn1I9/zfS76Vo0 lSZzdI2sG2siMQzL2T2LpCoS5SxDzpdqsdpLGDeHnMaMDjeQCvc3zOhotZdLmOcK81bx 5U4feOkJ9i0YcKjfAQzom7968iRj9IwV69MsM5bvi4XvLJpzfVFP1n75eHn06PM8z4QA n8Z8FI4xt7jO14V33xmBwwNfGz5JcwOLtgzC8sEy4uFO+TtGfHKjrCiUYv+pqjF50gfj PMYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688493391; x=1691085391; 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=VF3Qnv/fRo6auQhDr6SI8MJNl+7FJb8MLAYLmOcNyIU=; b=WckqY58g3a1Qk15IDUzh3rhpqk2CYnSRBlyyrREuKueCVSB92dAmsgrOnMTLJ1O7xj B23bJY3eEnU15ETD31BMDZD0HcBnok9+zdMyh9nupw+4aoGXQ9mcdcVuX3MLNoGcxHT/ YT23/seZ2OZfaeWHsZDy3wrdtMCGD1XhAcMVXsmoeyh8Zl5hSd6Zj0MaNM2VGjspm7E8 vQYQpgpQS6NPP91ay89ScDLoOUTFzhGYO10xfJq+SyH7kL+63fkmufsFBCBe9/4+bcNf InhamvAl/cKOO/qCV8WJmRMyg6eqiKJNbMF09vK0ibLwbVBekdH7TBlSzQURmsrTf6e0 1teQ== X-Gm-Message-State: ABy/qLZ2QyaOf/kpQy8E8wi55tbeLyuH5QVHrDr1LDdY6JXvinflrb4L BQSeVFOYHKNZM2388jf7deDhYjdvkgaskLqQNLTnWQ== X-Google-Smtp-Source: APBJJlG73XZpdtZxtShyLOV9G7f7AAaLS6oaInPGqaAhe3iMJBjlRxbinT8QKa9qK3OZdPhZtcVet7odKCEMqmAjN5A= X-Received: by 2002:a5b:147:0:b0:c4b:ada8:8b86 with SMTP id c7-20020a5b0147000000b00c4bada88b86mr7807242ybp.64.1688493391019; Tue, 04 Jul 2023 10:56:31 -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> In-Reply-To: <2efa2c89-3765-721d-2c3c-00590054aa5b@redhat.com> From: Suren Baghdasaryan Date: Tue, 4 Jul 2023 10:56:19 -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-Rspamd-Queue-Id: 071DA80011 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: j164xah59m91pnxsudsoukhad7wuzdhm X-HE-Tag: 1688493391-389455 X-HE-Meta: U2FsdGVkX19IkWNWdfFWmuXO9c3NBj+wvBfppJ6QEPGgjfSwz96XfZde5pmAICgTURGbGJe0mdQG9zU63EgjJoQ9YcvZCNRYJLqgbtyYiPkt0HhprO+TrjU74u6bTIJ9zCFzt9fb/utOndiGPeISowTicDsWJrgiGeLGELdxFfvj1mepr6vsDZkambkw6zgyqvlfhnxsg9hAFIySNKACKQtNX4vw20KmM4MZ8SKLn3eyBqmNY+yXPmKfNDrH6Z/TXT/JHdGCgSN3UxQkDb5ahT2wxvx5hY9uoo3C/JFT4rAjqB0kHNUYwp2smozq/rvRQWjGVWCi85h00jkgldFi9Zn6+EC9nhc32iQZNR9bRZBpTvC9KHKQ3aB9r/O72TAi/S1Hu4DV1p+MjLKhyjzOcR394r7FGjrpo/4XnCguwv8Qy083p9/a0xbHSQ7Y9jGZys3ts7k3Q666BRjlw2W88q8Asgq9up3yhFBavIF3jWdVOqdj9cJw3Pyc5F0tBSs/nq80OkL+OjAL1BebkoFFZ3ju0HTlYI9qAjd/OwBqbXoyR7Upl+iVF3r1Tzzx9UZvnEN5Klz/AK+17wseha71h9+/d/6U5SZ8fUepKQQDR6o5WVCbL/aT7Ti/NZpWV7Z5Q3xa6Q9FGBgjCMYjYipP+MwfgoDkLWeuoZcIWCHc/knfAakLdIZZ97nOMmtN3OZSlwCXdDogbsLGRoEncV4HSee9SedA6r8SHkJZBqY9q8M+2AbJ5fSe+weKHwdm7iwFGalsTCpbhCUn8vcHR3Za4a8Zfc4RNjldFNE+J+QShObpyKMRI3DAyg6NScUpR7N/d/QPaYbqiRSPhTBsS0bB4Z8KLkrE3tCHfABjI0rOV9+wO6COzk8eF2kIak63xkIl2XlIjWyLLG02gP+5qGJIjvj7hhrcEgjKOsOAtZGEZXO+YlnK9P+W5zNVuUdLP0Ts1Ml9gJN4KjkXQYkpwbR yVlU2/m3 TxiAbTYH9xA5U9SJaa6SHvsuREH3FN4nmfYicjv1bEP3XOP7SF2TJPUHYUhO1Pv/DCSqY/x16En8c6bJcCEPGoZ9IjLNMIGc7S/zxqfETMzyezSkKCGUlftVbQB7RyByyOUcYZV0p3YEnB9qtFbkOHdRT/uuLLOeaZ/wJ9PEwJCHP5HCrLzZnCJ/f5FoyqPUS/D5YZr7H+VZRk8AfriRTMlJWi7aU6+fbn4u3a/TnrufEH9GMbrxB8xL3EPvEFGFaf2oI+CgsdzjwcUaIlKQ3iG95QDZjmhWZ/8UkgROlrKLVHu7E90jD+gK/7yub4nWxlVWOcF5zex9GQP0Z0GBRF49IzZNJjlqAu2bKCCCEPvVf6klBOwWzE5Esrorzx8b2pbADepp3pJDIK/DyODXTZSMr91S/yftG8fQijeyacQtqLUtGxpJoOvcDYDLAY/nVQQy3gOjK/hnByjjlZN2DUUU3t1clnjGNRaapa1J9FHOOZ1w= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000016, 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 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 now.= But > >>>> I wonder if that's the best way to fix this. It's surely simple but > >>>> 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 concurrent= to > >>> fork(), on the yet unprocessed part. While that fixes the issue at ha= nd, I > >>> cannot reliably tell if this doesn't mess with some other fork() corn= er > >>> case. > >>> > >>> I'd suggest write-locking all VMAs upfront, before doing any kind of = 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 a= s > >> 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 make > page faults fast and to make blocking any page faults from happening to > 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 page > 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 for > !CONFIG_PER_VMA_LOCK, so that one won't be affected. > > Maybe this patch in an adjusted form would still make sense (also to be > backported), to keep the feature inactive as default until it stabilized > 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. > > -- > Cheers, > > David / dhildenb >