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 41745EB64D9 for ; Tue, 4 Jul 2023 17:58:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C01032800A7; Tue, 4 Jul 2023 13:58:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B8B6B280096; Tue, 4 Jul 2023 13:58:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A2BFD2800A7; Tue, 4 Jul 2023 13:58:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8DA22280096 for ; Tue, 4 Jul 2023 13:58:53 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 660571A02A6 for ; Tue, 4 Jul 2023 17:58:53 +0000 (UTC) X-FDA: 80974690146.17.82E07EF Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) by imf16.hostedemail.com (Postfix) with ESMTP id 7D3B1180007 for ; Tue, 4 Jul 2023 17:58:51 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=70071Zbr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 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=1688493531; 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=sJ4NoT4yb0xit+42u3FseNoABGzXLpY8LWYtbPP1X/s=; b=4itewSj+W0qwXkDVjKc7w0Rmi3PVxnq3aCO3EY8n7xTv/3YMuyoi1g4fKsH7uzx/z0HSqo DcnT2sJKSQ1UGvh5NMkz8pLVqiCtkhDfukQDyd8Y1IVIKqjxSSaCxawDcoT9oZQBBuYRxV UWBRNpjUsQ91YyeyRqsXLkxY+P4LWV0= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=70071Zbr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf16.hostedemail.com: domain of surenb@google.com designates 209.85.128.172 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688493531; a=rsa-sha256; cv=none; b=wfV68QApBPNXeh2pLPPsS3v5SIK3/9L/1LqXFr394mkBKeF4LsdZmPDTL3ktvxy6HyP2jS b8QAvOk6vaLj1pmZavU292snXtses2+8i1Kku4e1QJykVRqg7NfxcFMxe8BddA2K5pDvv0 htyImSqIpJW1bcaq1eZvBgiLPzVAUi4= Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-577412111f0so60672967b3.0 for ; Tue, 04 Jul 2023 10:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688493530; x=1691085530; 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=sJ4NoT4yb0xit+42u3FseNoABGzXLpY8LWYtbPP1X/s=; b=70071Zbri4QGmc+rPGzQLRv+Mq0FKHNnFVNOdlYpND0S3tJwdGVIIhPRPG/pFYJx8+ c4N5/v0GdJefTd8wNsbODfbbDK+u7Rau54VyUiwsRTIcrfGgBHM4kJ5LZELXHyWjyM4r TLdZvYPE2232ce7oKtTquZ7yiUBx0gX4H2t1qKIeVEIL7qqN+xCA/HbATDd6Y8pwFFgF WdwVM9+maj1SNWTxoMHCGIWE4lZqJZf4a3eLVBWIvL4QFt1adyDoufa1O4TJXuP0gXTY rN2EUEkUN/bvOUAXiOqXxLfZeo3XqAOoxNJ7lwuSuituFUTd9EtNGOhoj71merpvXI44 eBNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688493530; x=1691085530; 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=sJ4NoT4yb0xit+42u3FseNoABGzXLpY8LWYtbPP1X/s=; b=kRC6fkoIMzKIXfevZE1aBJG58RenChj52xVqVkEM6Chr9lrHzSJH7DtUp0sIVRAHFE 4qRJLdzmI9Bj4If/ArHroHXl3o4eZ0HGnkNU4KB2UDQtWvACfMLjdYQmWpkwtph4Ua0k AJ1QiLFt790iON+Q0urmL/mv5TkrBDjdT4frgk8WHXJd/K8kxYmh1NhlfQHE1iwjmSCy z5VMo6kkXxVkpt1WlTdDtJqLzI0+VSUzdd+U/T3KV5AFZMqn58kTfujhBEHK+4YNapsl ikPImn6ksH6YV1eIFL4FRqDMYRS2V/6tDw3zFxwqvcxkdJFicuRwIEC9Q+D5ns5Yop5A VBwQ== X-Gm-Message-State: ABy/qLZd6ipz3wNW6BtpHXf3sei+wIqTEPmVcCB+bcypVqstalbMtt40 5SK96PXzky4rEWH6QLD77uxk89+mc3lRm42n3n/RqA== X-Google-Smtp-Source: APBJJlEnOzWg1IoMbW7DHhWFfbQcNRsmJthCnfnPP2J+QN5b5lndvhSavkq/qnVebpWnkn1EX5K9LnhI6jZhExwiUes= X-Received: by 2002:a25:404e:0:b0:c5d:5430:aa15 with SMTP id n75-20020a25404e000000b00c5d5430aa15mr3300347yba.35.1688493530403; Tue, 04 Jul 2023 10:58:50 -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:58:39 -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-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 7D3B1180007 X-Stat-Signature: ih15nuad1dh5sfubf436zkpw9i8h8f6r X-Rspam-User: X-HE-Tag: 1688493531-305983 X-HE-Meta: U2FsdGVkX1/hJXkSyynf7+s4ti8s9DOJ1pvUtdXqdsWNeWQCgoswbXVkhYKPwoZyE7RwsVWUomGMy0avtOgXEkaQUBfFRLNl3U0sizjacZbD6jGpVweI8OMZV96eqCHWonA5q2t4Hz+8FFvTPLTnORHQI1FIyNarEWwOeSpC1H5r7bD35g/wIQ9AYcH7Vj7eU55zlPw9x6ByDnMqifGPRPrCS9/0PrVSKYFSQrQyub5jSz1L5d1DUtRmZankubbfV0q9VS+8qAf/mCK0Si/U8/FPs2VJ23+dJHCuUsU9b083Jo4ZLiH1NPK5CjZICiIkHXcmENyuSbpYzmjlcmeRiXX+ZuRmLzERPvb2ga7YhcAyjt25LVhz6ti5gJhChtwf0iuGFcQ5WohQdMzIS9nB9lXxqij7kPv4UCZE0RIaAiTJM5IZWMWHFvRIBEh9TO5gvi+yBbaWPyBL9qU/KRWgsDak1foEDeWtRL7+Fhxq73bylMBjs0WnFU8xQd40YTlkIbdH51GF2TaRmnBORtNkHu8r3OTGOwa7FjHccXM5oaezFmMDTMdxVh20xV1E6k3OEf8GckCcc5tkdHpPfAB+/mnPCsuQc9lZH++3jZ6fHJ8AQEZUrLDIXp29XHJGY29h+6rSXVTAxdUgRjJ3mv7rTkgP/FTzDgcq257JW4zNinkGk9DSk9/o+CTlsnG07NodWO7ISlsua/e71fsZEQzGtvbb/V2ePJC3nk7TASZPXgmyNJDRQFq2m/b1nwHMwcKWAycTL32gymuV4hq7L52Quwk2JtP5A+kmkkuwP6zsJbZ4XCujU0xAgzXtyJ05mc963XdCGCMydAzBQ8CAxB+2vl1v2l9rkUZVkORPC79Yl2ZKxe3jxmxa9yS20MOeJx7SWJXKwonwr5ddknAHFwpfdbgZ4wcY0bZysosQxCFkCEfrcgGdK/ZmLy7bvlc2WIzkuK/nKbMUkd6pNUa5CPR Y+Psm20v IJRQB1O4x3wkrVh1oS7IgXYyap33V+I7qVHW1dp5iewjA5MqTBf3TotHD+CYjePZsInDdRzlJndgYWn9wcXI8W1hid/ptOksD/LXLMXBMNNJesl4sDK5SZ1riZHtkYSsBcEzrvJBPIh2MCkL4dDHKSRcXdx84aQRGhwjB/eYLA5RMEYqHAm4Jdrtrn3sjMa+212q6jy7Dj6vn5BIs2rHjAGJNl1PXgOSRiYcJfoKxo+jxCzoJo59iyD3yTK5JNmPzlUou6Rp4Y8TZQqAzLk8thKgKOzImX1WoKZ7RE0E4/uj1cz9wmvjieTO6oa1lUS1MtOfrUhumB+rH5x/vm7eqp5/INcs1cq9PsgtzPH6zwmliabb8C+yWvwVoOnPRWRsTugzF1Z5YK8x2KDSMuTtzFLYbxw== 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 10:55=E2=80=AFAM Matthew Wilcox wrote: > > On Tue, Jul 04, 2023 at 10:21:12AM -0700, Suren Baghdasaryan wrote: > > On Tue, Jul 4, 2023 at 6:07=E2=80=AFAM Matthew Wilcox wrote: > > > 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. > > It might make sense to do that. Personally, I'd try to quantify it > with a make -jN build of the kernel. That workload is fork-heavy of > single threaded processes, and if it doesn't show much difference, I thin= k > we're good. That's a good idea. I wrote a test to mmap large number of vmas and time the forks but I'll run your suggested test as well. Thanks!