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 B3F07EB64D9 for ; Tue, 4 Jul 2023 17:21:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1FEB22800A0; Tue, 4 Jul 2023 13:21:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 187D0280096; Tue, 4 Jul 2023 13:21:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 027EB2800A0; Tue, 4 Jul 2023 13:21:26 -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 E47E0280096 for ; Tue, 4 Jul 2023 13:21:26 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B59234038D for ; Tue, 4 Jul 2023 17:21:26 +0000 (UTC) X-FDA: 80974595772.12.6BACDF2 Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf26.hostedemail.com (Postfix) with ESMTP id E4172140011 for ; Tue, 4 Jul 2023 17:21:24 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=NdcWO6wa; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.179 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=1688491284; 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=inbihncz5oXXxM0l3WLEQKOiNKkubTdZ2uuI1YwlfYY=; b=XwY+EjZmxGv0iTttsq31x/ictOgW4mXt3smjGCzNC9npIAcuovY9JYGzaoljt9YT/CDK5h lHfGKYcbm+3Tlpalzx3IdxEp/1pLub77MtOF9jdTWLZBSG4SaVP/gurhwICADDejAxjUsb 1l08EIYQP/k4WhJSqZrtpelrrtiawF0= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=NdcWO6wa; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of surenb@google.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688491284; a=rsa-sha256; cv=none; b=lWvmPARccSWXiuQcNX+1TddiXDRO3zsm6rnABeNaydBOQkgxqNVIpZEMcTW3SP1youmwdk jSxk70Blc+wVkaouJ57+IfDeWkG4fZIrEMtd35gL+oDgVlvdTZtNiwkWtg+BxA17MJaHQZ 3LsKTv0ApKVlOKWQi+VHBIjj5POVlc0= Received: by mail-yb1-f179.google.com with SMTP id 3f1490d57ef6-c5cf26e9669so976473276.0 for ; Tue, 04 Jul 2023 10:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688491284; x=1691083284; 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=inbihncz5oXXxM0l3WLEQKOiNKkubTdZ2uuI1YwlfYY=; b=NdcWO6waJL6tvEOF+h7fTihvuzowX7zLOyJb7v0RQWigyd5sQSnWleoOFie6y0PvCn 3HtT1p9/KCEhGSWSTyLNvdZS4aYXpxOl3S0vk4MQim9TSISWxl4Zza6OlylxEBeAX4QS 4eEqHYVybZMeAXknGO3S8cGPRVCwyU7GHwBM5qzxdda/qWDLVwqY0oTIj+K/mf9aLMUg q93vmb9WFWx+sxS5UGsE5lZZp7YPKdz9oqBi69kKydvRrUEnnKApSd23YYn8gryiej2Y oFjP6oWehNGgZwJ0AJgHAZTzePcFBKsgJCE3+gPgN92nV1WrrYLra5fxcq0f8E8bsXom xNbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688491284; x=1691083284; 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=inbihncz5oXXxM0l3WLEQKOiNKkubTdZ2uuI1YwlfYY=; b=BbfqopJMDG63t3k9SDVvZI2iWhaeKFFAMm9lKc5dXpLg6V8AO9IUhrsiWr9xCRfcP5 o9h1V/adH//v6xjghn3MqOoscnNdMOJsoy5vJCv+1TvD96l8pwv3fWQY5GRnaHExAalh mdIHbDGcnzPm3vh72/ZHfvII8gjtA39P1P5yk774mdp89yfYthn/sFDi0Y8WLvA7OgEL vjyv0GKIcj1Zk2tGDpRNlgopHeS1EzLOCNbfvG1zh4tBr0j06y6BUbT8RQ2kf3jNlAoZ lI4+IUdeX6y2pWJEREP0KTRNhLDuyMVEcAEirbygLBdmI+gkw7SwZzZtq7Ij5KFnY8TL TuvA== X-Gm-Message-State: ABy/qLYFLvUfERslGACMD/Y3lplUDAcUP7KUahs2cOx6hT8p+inx8MWs enf2f3gXqgHosqpYQmvXGO9rnozD/wHS8Y5JuzVpng== X-Google-Smtp-Source: APBJJlEREJvPhUvKc/dN4w8CiLN7mI58EiMQ1boASjKnwMm4aRbMGpzPt8rWL/7e6YcpOSFEW9oCj3y9wI/yeDtBhvE= X-Received: by 2002:a25:842:0:b0:c1d:4fce:464 with SMTP id 63-20020a250842000000b00c1d4fce0464mr10771877ybi.9.1688491283688; Tue, 04 Jul 2023 10:21:23 -0700 (PDT) MIME-Version: 1.0 References: <20230703182150.2193578-1-surenb@google.com> <7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 4 Jul 2023 10:21:12 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: disable CONFIG_PER_VMA_LOCK by default until its fixed To: Matthew Wilcox 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: xa4fo8y7ftgk8u7rbt7t7gfbw5955cye X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: E4172140011 X-HE-Tag: 1688491284-516239 X-HE-Meta: U2FsdGVkX18AZ8nwt3SkQZUqYPSAK+xd7dnfM6Pv7SxB7Ox25/0tunAytEnPJ1sPBRCMwDkFGFx74ej+Kmi+SgemZdDUuk33Qn4gPtcKTwVr3G1p10lX/8hTGmDXXgrEFKGbGSiqquIOWsmOC4owWX8RxFAFJz4UUXc1YlASDXc/++4n4WXNBZVObNPh6jihrPx2ze/8Zc9BOv5JvqMKp2DhkSy0/3YlT8QCBxhW4Hc4xDQrnUeqtz6WUPDXuAHOgMzffpdq+QHrOxl1qvQQMB179BKsP/8VNstMR8uDTsnPamsvPE3jqh0cqmmucFxqEY1LYs2SX3YnjV1AT0d8p/pc9eM/ACUlGcvxfmwdQ2K9jfWDnPTDAJLHsv4buy6O4bPcOGFKvjLRZN472gp/ktTQJLM3A1qmr7eym3edJKewkK/8mwwChdl92F/+SNEowwLDLy/P3PHDPzYOvBsn5rnxVyAKIBpGZ/RramES8MxKg7SeQM2SUeI48TKFIYWd7hjdFBv9Tat0ODCUcCjPtR3EqLyuroDMoDQx62ufTcJk9g1ptkUSUIEBcSDH8W1rnZKVPOjb3HO+yogl4Peu+jlg3M2k365Y0Dh9Z+3e8dKfl38OdCqCb5Uv6m3feObs1FctI5De3I+4KtxNCv7EfAPNUMnc6u34uMJEYq0Wp3tHSVid7sZRTHRFU61MPWd8mwB+gVd4X994gaZ8UwnyzliJRZ1haLQ3u/aVtNDRN9SGKAUrzBsqWYk+Vu06mQjsbjwRI8tPyrhpoPJ2eXYWhr+4a3LacNao6Nppt2nJxa3pWRpXe2/aTXwqyKQ9HWkuL9kPv5c3JhFNnL919Wfaytgx6HSAZPAj46ke2yYYmKOYphP3RpYKEi0463bYoB1fyvdpa1skM7uhyWurXTfek8yVEH0esGPPKVqAkWbBVlitMZNrTKgcD+CeorRY8XQgQ23RC/pHrk2+VLJA4ip /WEAvN25 TnBCkMe6bgCpWFXhbIhUBDjCWEItMc6+kVlsUKozaxjTEgAyj4yQbUfsUoX9pYUf1jFFJN/3eZ2M7wIjecsK+C7Xwi+B1DnpUm8+V7k0xw7ZO/dnCS7CnbwypZmoxN6cQTE3U4nUZANiykMmKHx6y02XIjvZ3hofJC2yEuz6v25Tp3KMeZvHusxuxB6P2hTLa9s1a0fCA1nMYccAovi94/i+kgGm5sZ9AZ2bSTe7ZIGiKnTMSDB1F6RZEsUmR9ngrY4Y2AUnHmS0sHS8o3MIsWxzs8kbZKWrZQCXbrkhSJRZ3uOkD9VqI0vhPcj8nd0ZGGjRrWMynM22QvoepHEcCF3yC5c9SqMYE3W3ZjriW+wCE2HJ2CO+bjSuHrUpqAqfPtf1X0pXlMJTrLiK8Zw/L/uNfbPM5YWkvZf7Tl4hI+4O6V8JVhp0wV0uDC+A2VZiKgZGiWmIboJRvKBxlMbsuNVIGPxcUrLx2bPV/xRUEFtLkb3ySVt1QnC3SFGXnEnUxXqDoxtdq7bgx8j+436Wigv4UKoTo0sddhJQ7DAYHBJfY5uI= 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 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 t= o > > 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 fo= rk-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. > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html