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 EB15CEB64D9 for ; Tue, 4 Jul 2023 17:36:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 68C852800A3; Tue, 4 Jul 2023 13:36:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 63C22280096; Tue, 4 Jul 2023 13:36:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4DCF72800A3; Tue, 4 Jul 2023 13:36:20 -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 3E665280096 for ; Tue, 4 Jul 2023 13:36:20 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0938380472 for ; Tue, 4 Jul 2023 17:36:20 +0000 (UTC) X-FDA: 80974633320.26.100765D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf14.hostedemail.com (Postfix) with ESMTP id AAF29100013 for ; Tue, 4 Jul 2023 17:36:17 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=b+UEppqW; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688492177; 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=PPSWitRQyHLbGlINOhEuvgFby/IQGbpLvq1xZWIe6NU=; b=kJHvom+QusfDtQOEltmz1/oaPoJRUIHTArOefx62Q70KFxKKs6YecTkIvwVPycQerJI7xN 4jrCF/3S9sFPKkGirdn2R5BUU5exU5zWHq03D1FICuxboSCQ8Y8rPBEk376nk2s0Vq7/jT x3u+g0TSSZLpo58AIDaW4Mw4lAmNxGA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688492177; a=rsa-sha256; cv=none; b=d0x0xT6QmpirTvUDPDY7VUhIMgBGcutHmIMT2OvFM62R73gYU0Y031YdE9cUIfp9+mwEQp xWLz9fIye0Gs/PjZxGu4pBGdeVlKUKGRi9z5XhQMauUHc1ZGcxbb8jxLxhhZfMWjqa4GBb BI9KVK60b0UlWarjDUGK2xa5tJCbQ/c= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=b+UEppqW; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688492176; 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=PPSWitRQyHLbGlINOhEuvgFby/IQGbpLvq1xZWIe6NU=; b=b+UEppqWVlh9V3zh9mPlGv+HnD8d5SxNS+V0ZqI47RoI9dtESW4Wvo+Pe7o3USd840r7/k dYu6l5B4peSls2rS/zIWUFywnbAvljAXY78bXDNZGmOCIzBWdQJAKKS0vdAeShtiUctiil 4AmKBxFqfcQK9bC5zDPTKvPwPj5CocY= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-19-csp4iBROM3in3C4aHLktOw-1; Tue, 04 Jul 2023 13:36:13 -0400 X-MC-Unique: csp4iBROM3in3C4aHLktOw-1 Received: by mail-wm1-f69.google.com with SMTP id 5b1f17b1804b1-3fa8db49267so34229735e9.3 for ; Tue, 04 Jul 2023 10:36:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688492173; x=1691084173; h=content-transfer-encoding:in-reply-to:subject:organization:from :content-language:references:cc:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PPSWitRQyHLbGlINOhEuvgFby/IQGbpLvq1xZWIe6NU=; b=FGPovdVzibYxesFjFHwzKz/LEWrG4DF1cfKjx5Wks7J/3lXDrg/Odd9HDNq2kGuTKU UV4vLf6meqJJCWJ9jcEH2fd/rdGpom8JzGrE637dfCQUPccSUFQHLQSgQ9fTCKLVkS5w SY4zyfGtLFZLJrL1Qi/GGY8Pi3K8qIrHD1ZyACOGuQNKKQmT0Vq5I3nHLfoC/PTddFkR NoXeJEZUg7bShyuxvepiW1oEQei5W/enBHGrgEE+nd8QH5FNBEA2GBao5aVYKUJIGdjc k7swVszMiQYtLlIfUWqS8tXacqKS87h+BNdZhF1RRnDpuiIXw8qn4clpfz1KypwD1rL9 TiTQ== X-Gm-Message-State: AC+VfDxoaDjITUtSq6xDe8bGgLIhhMd5zaL5eILF+PQEbcfbR+gSt4IY 4CyTX15CKjDY2js0r76T9rdVTTlLMnh3OE2ac/4FZQigJ63jV6E99N2OGwElVys7hSag+o0X+ua xSE69fXpDlBY= X-Received: by 2002:a7b:c459:0:b0:3f9:b19c:aab4 with SMTP id l25-20020a7bc459000000b003f9b19caab4mr11509664wmi.6.1688492172762; Tue, 04 Jul 2023 10:36:12 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7gaGZdDh1q3xHn4/Rk1TprzpfA/htu3FImiV55NgTCwG1c5/4Bu2RAWxnQsvPRLcJxkJGFnw== X-Received: by 2002:a7b:c459:0:b0:3f9:b19c:aab4 with SMTP id l25-20020a7bc459000000b003f9b19caab4mr11509630wmi.6.1688492172235; Tue, 04 Jul 2023 10:36:12 -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 u12-20020a05600c00cc00b003fbc681c8d1sm13471779wmm.36.2023.07.04.10.36.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 Jul 2023 10:36:11 -0700 (PDT) Message-ID: <2efa2c89-3765-721d-2c3c-00590054aa5b@redhat.com> Date: Tue, 4 Jul 2023 19:36:09 +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 , Matthew Wilcox Cc: 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> 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: AAF29100013 X-Rspam-User: X-Stat-Signature: e916mq5ot99poz1dx5oj3qntfm5ruqik X-Rspamd-Server: rspam03 X-HE-Tag: 1688492177-56880 X-HE-Meta: U2FsdGVkX1+r5Nx5NSUR4QVqxdD3eHSZY/fpPmCYqnA+JOBdT1qoGQ7sD+HWhMwllJHrUbkrVzlBZnF5h5zWVinnFc3ziVrkZAj1Q04NmeBO9nPLUMvFPbHDNISF/1hzdwZjtQUexb2fdPGlvjydCYRcLRKnD8XoLmj2oQm+5RePe/sN8ZgSCijtFTTV84Fryf7nDsIVwooAJlMXNKL1dLjlvg6S99cjJpThJwM50Bd0UvLpsuA539GgpeCjT9J+F0HSciQf0Em4Y7ELCnyVGdPKB102aSh3OIztAGi3Rodd8D2wm5GkxHuP0wV/p8nEGrNn5kDn+rkd5CbeEkfCJ5zYbFJYvwoIVKu42wrpUDVlZdaXedGPmn7rg3fda2cA6DArAyLbKYaQoGT8PECNL10wfouGyMWQ8pxGpe+hK1C2mYGPxKQgVan1nGpocPrl18KQVeQ7bIdGULq/7WhrEOhYMlHPXLxj4f4uiS7BNLgvLsSGLDGBFFxkg3AXYcoUmadgBXA09s176q5WzTwNnetFh6rNic8cLesSmU2UQynZjuy51WzKoev/8HlW8RnryCPG2I2xYOwjb1JFbudEa55dutJP/QDIYsnm7wIbF77pkB+KYU6cQUx1kcePidgVBjfXEWecM7b7zdfS2dMg0lN+rk81OH5b2q8kofxoLkRUWAU/LvzgKPtqBQjDNXz/IpzkyJM/OO4WhQf7Il06oynh7qNZGhPyWQxkgn9gE15qfGeckA3IkWwUxq78CeTXUzNkUzMPUYYAiCVLbfKMsGtvZSRL+I4Jd/IzKDN/zk+Ok9eAh6eX1bA40vgCcNiyjqbAqP7dNTXI/jlsZ7tFsRQKo1nj+uafBAcu1ACvoyLIamM2X2bJZFetQ+r5+yzfIG6bLUQwFwdfFEzf0S+thpeoEg2Xei3qPUaVg0MVJRfpiEQeCJJ7sRjphTyGQwZM2rIWUDm/ZlEIh1JJ8BW aQfjrEUO 4JHLjgmK8GHRqOcPoFi7eFoSCqq9LWt9MzADY36B5sVuNouuOKQ0EeS2xJFE920lYtTNWfp8L6G2w5cNBvM+wmlm6+xY+Sf7Gyn5+gUt+qCiwbo8KKM0V6lGBWqcBI3cZo3ZAcVaEptWasrpQYW6EisT/wEHWvyPgijz0zlIg8ZtuWYoD4BGON19EpMtcJ7JNbxT8NYbvyEq/zloZ+acnQlQLQ2M8Aiom5u5CS2ige2jxTtp0lpUQ4JF68CU2ZJ8mry7Bc5WTt9VTs+7eFNndVWtBi/0N0gWemH0DyduZEg3OgpDdxhPcgf5dbdZfqRM/U+1Fq2drhpwNFZ86gAil7TcH5xfDiTzF9l7o5FFxiTQ8Gsh9TvfdrtQLCSVkRjpVKRjtjag9WAU51Q9AnBMW3vYjyukSMbGQ8PFPWkhBlzB8N/PfcHMpgog01esVK+wwysks8+2/jifK2L0KO5cdOr7vnGESnodUTlsxgNLgWiZCrqb+IQ31rI7fgcYwgqrOpQQlir6PAtkWN+Ludn/CuW4uXkwsjt/QU/Nn6fmi31WWPtvT90a2dj6gTeq4GNdiAe/WkuxvDH0QVLUCR/A/BGzgthBWzfvIZwt8dzBFR2dCPVZ7X/UBfJTJtA== 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: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. -- Cheers, David / dhildenb