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 93645EB64D9 for ; Tue, 4 Jul 2023 18:05:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0DBB22800AA; Tue, 4 Jul 2023 14:05:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 08BDB280096; Tue, 4 Jul 2023 14:05:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6ED82800AA; Tue, 4 Jul 2023 14:05:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D6F3A280096 for ; Tue, 4 Jul 2023 14:05:11 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id ABB101608D3 for ; Tue, 4 Jul 2023 18:05:11 +0000 (UTC) X-FDA: 80974706022.05.FB35B91 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf12.hostedemail.com (Postfix) with ESMTP id 5908D40011 for ; Tue, 4 Jul 2023 18:05:09 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="V/2COiTn"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf12.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688493909; 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=qkpPAEqN8Y7cyO6i/C2yyjkZ5smImyut5Vb9z85jZDw=; b=Nw0HnGe01+dHTHRwDa27jfnK1PWtM9T/9jcR4FQC6mW26puE76vPPX9xSKUKqquWhA5z2o EAlu06EN3wLILbyand3MkEag4hn7JU2C+WlFm69TWqclBNzSN6E16l6X9sJ2M7d98F1gsI zhUmoDOX4exAezFRsJb7Uq3vn9xNsIc= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="V/2COiTn"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf12.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688493909; a=rsa-sha256; cv=none; b=OU2cY97MWZ9ZtvL29N6GJFVG8h1Q7lQhDL3ysULY8WHVVOx2zuhZ4E/JtSSyU3pdUpuX0a 4TybD5XQk83aXCENGge+COr+DlSkk/Tsv9dCw2yHulcSUmvlXAS50l7pC75FTzr0B2EeSp Y9rxTcztjMqZnORR9SjD2zTx8fegAyM= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688493908; h=from:from: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; bh=qkpPAEqN8Y7cyO6i/C2yyjkZ5smImyut5Vb9z85jZDw=; b=V/2COiTnYUhYnbZoFDIbm0+/gCMY6EFEk1WdoWE4GlHuYFMPw+e5mqkZ7LiWxuqoy/sHhb dcojFHb8fY+cOoFdr28m2y1+m+uM/SCjAVaqKtQaHnDUiSYjm2MYcZjvGnxgTHLJabZW0T cnFTH35tGN/cJGnXLQdIGPlk4pbnv6Y= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-313-zVdmS7U3OXCRX-IUYSVLfw-1; Tue, 04 Jul 2023 14:05:05 -0400 X-MC-Unique: zVdmS7U3OXCRX-IUYSVLfw-1 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-3f42bcef2acso34180155e9.2 for ; Tue, 04 Jul 2023 11:05:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688493904; x=1691085904; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qkpPAEqN8Y7cyO6i/C2yyjkZ5smImyut5Vb9z85jZDw=; b=cxixOZO9A0E1Sl00Evo4ZsINE2ZcevuwJd+10i9AWUAEg1KLrs9eLsr8WxUtOyevSf mGTrFKJIUx1L4IfdnIf2dSzcqTWG4DH+2xt6mIVl+3ZKZUk1Oe/w08jsSzsN9UvBZE7a 3uvkR41k5tmTmmjxLy51l/vImEMdLVmhZItu4iVEHxR+ByclcX9BoOf/IVkzfdxBKiWs IzhtYlakHpxRvzlWT7BByB8U2swrABpuD7OOLoexXpnsuqDrMEERGjLbi7DSfR/YnXEA uPKX1Oz0RV9m+VC3HOj0bTTbHexIdBkJr79UnqmQJeyaZRZHE5yBnz9vwu/a8fE43H3A jTQQ== X-Gm-Message-State: ABy/qLbQdl+9jZnwoMD00wlo357XdWhJe3KawwSuZOMSclOe+sfjaJ17 iLRCleNwJp3RD37SDU5g+3r2vqpJbhBBjT+4lBMmO4jmM6PwrbOOkQmFCkoL36f9Ys4oi5UAGg6 OaUiH0Kq1glk= X-Received: by 2002:a05:600c:2041:b0:3fb:e189:3535 with SMTP id p1-20020a05600c204100b003fbe1893535mr2207972wmg.27.1688493904584; Tue, 04 Jul 2023 11:05:04 -0700 (PDT) X-Google-Smtp-Source: APBJJlG5q2t8/m7F9qenn2zMdRSOF1cQmfLBlwHDro9yBFzV5IPuyRd9c4FxONAG/e7t8REA1vlY4w== X-Received: by 2002:a05:600c:2041:b0:3fb:e189:3535 with SMTP id p1-20020a05600c204100b003fbe1893535mr2207927wmg.27.1688493904178; Tue, 04 Jul 2023 11:05:04 -0700 (PDT) Received: from ?IPV6:2003:cb:c727:3200:b69e:e7e5:8c5d:21a1? (p200300cbc7273200b69ee7e58c5d21a1.dip0.t-ipconnect.de. [2003:cb:c727:3200:b69e:e7e5:8c5d:21a1]) by smtp.gmail.com with ESMTPSA id x8-20020a5d60c8000000b003142b0d98b4sm9768841wrt.37.2023.07.04.11.05.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Jul 2023 11:05:03 -0700 (PDT) Message-ID: <3c042dcd-192e-7050-07f1-ce891b95dfca@redhat.com> Date: Tue, 4 Jul 2023 20:05:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 To: Suren Baghdasaryan 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 References: <20230703182150.2193578-1-surenb@google.com> <7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com> <2efa2c89-3765-721d-2c3c-00590054aa5b@redhat.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 1/1] mm: disable CONFIG_PER_VMA_LOCK by default until its fixed In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 5908D40011 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 6m4cztx798ejqwqbaqa5b39wz181x176 X-HE-Tag: 1688493909-921359 X-HE-Meta: U2FsdGVkX1+fAzoU2qfOXZ/U1VGgKnbAzlwNVhUlxiq+d7eyEflhsLXwtwBq8deFC8RomJH/w2I7dJJ9vZfp6UaE9mjxwAfprVwAuouKXVqbKlMWz05DBHsoOSLXLnremxjNQrYx7/0n5LN9zjb3lvIWBtQny2rtj+ET3w+5wk0jl9QFH+9neR6DXDexnmyjtXTJ1Nv000GpW/o6ggVjstckSf9SoWTEE3kt5ph3lQSfdo74iUTcMJT0V96TYIQzCqJtG7HYcKd1Lds+i9cDnqW89U42b+OPUW+agU+l2LADx66lglzvaQitGWNd+t44eukuXvaULBST36KS3rPr3QY8a2BywPR/rYgkFtsvFyrJfOItHpwcEYGRWkWWXkOtHzj9a073lyP1OIeWBtgXM0eFGGAVB+CMR1jzowx8JEBLZHMw1Us/QRFE5ybGZAgs41o7n3X1GuTfJQFGrb56MueuOcFleBS4JJ52rLsyJH/V84I18fK89a7baDekKaUio5aBJYlwX6obdJZ/odGTNnuUsxm0bc1wJRVVgWsvxa9gdkP2XCOb58Mq7CmWbTrbzqVaujaPIJ+oZNpoo+76SFB5EZmvPcGtIvC4vb7nhuVZ4OjiZ7MFqeLvovzxfXnwQAVHMJ2i7I75wnDTLRBlI5qZry4Bt9ijD+wBQS6L+PZ+lUffZd8Rhyj7w/ZxVWtQr91T3bWhz/QaQ65rpw1ADMxkWyR2tNywU3C3FYu9eINEelLodRNbxpQ3xSjpvCnLtfPGZge4xdb1OyvnRMN0rKfpvrUuGNDiws4JVDnobgQcplF5ohpGrpVoDYAPTb4MlYnnUePVriCLltHPzZoJpdBi9n8ANNowdrDyXOzuEBgwvk9kaJqBHQN5G8gonXVi9TxFcT+/Q2+L5dfgVkPlMyms2PaY7NEMew4g8BnusnHvzqWFSHbwMKPbQ6RljvtVM1eIzYWpQ5UDKK90q4G NJ2PnKeH XGZhsttkFqrA8VH2uPZv1QOUxVvoikM1BcwpcoHWmia19p7HdhsNLPE8O4oyG2JqDPYBbblJydDb/dBFirl62pDTbJM6K48mrPvmPCnsP1sKtDkIBzF04xwEJHsR7EuwiCJD3DXSZ4mxxzt8o0yf4PTPPr5/CLdg8TXEBvnp91RyWofDBEk2Lrm0wDT2IAqbLt9mkKu5ReEEEcqZ2ngK1iZlMdjAtNMBO8qhrsSQaWlcTtMAEIgORF2zICcA4ZfINQelWpjprzKcPs1epAX8Pm09dxIU5rVN/8c4/t0QctwMO6r//s+R6894kEiZGY44Wm9aLGYR1FOluou3eBrpDbpTBTNA5gTKERgc4V6E1yYK2dtua6o8GfFJE4ZyAbhKTXvL13sQKGLRzjmF3pHtTjT7IrBbDjes1uNHUjDHwo7a6kmzQlQIDilUazojYwpxyxz06kGAeJKl6cPXD78Q0ItutfeUzhqMQQpwpTIOvNZWxxcYMqKh6kYyYtdli7trmXLjObFKn/y0FWfc4IOyvNakKGg7+x/I6CGrz+UrvXMu0hbRGlYvWD6psgNXiZ7lDas9K0gOATotSBC4qujHR0RQbBAb/bbCQ3wTFmP/Pd2v/cRvKBSWCo58DPoEe61n2OUp+jythFRqQuKg= 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 04.07.23 19:56, Suren Baghdasaryan wrote: > On Tue, Jul 4, 2023 at 10:36 AM David Hildenbrand wrote: >> >> On 04.07.23 19:21, Suren Baghdasaryan wrote: >>> On Tue, Jul 4, 2023 at 6:07 AM 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=217624 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 hand, I >>>>> cannot reliably tell if this doesn't mess with some other fork() corner >>>>> 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 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 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. 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. -- Cheers, David / dhildenb