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 11756EB64D9 for ; Tue, 4 Jul 2023 20:11:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E8E12800B4; Tue, 4 Jul 2023 16:11:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8720E2800B2; Tue, 4 Jul 2023 16:11:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7117E2800B4; Tue, 4 Jul 2023 16:11:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 5BA172800B2 for ; Tue, 4 Jul 2023 16:11:14 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 35345C0186 for ; Tue, 4 Jul 2023 20:11:14 +0000 (UTC) X-FDA: 80975023668.02.A7C47F2 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf24.hostedemail.com (Postfix) with ESMTP id 5AFFB18001C for ; Tue, 4 Jul 2023 20:11:12 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=hOdDIaFp; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 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=1688501472; 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=yOjdvBOwTGuWn+yLARgRT5neCZ1ueI4UBq46eXgM3ng=; b=FpELCBK3YARQhoqlqVXUGN8c55vRPCG8g5dT8H1G4XDg1nA/J+mkVTi1URsRKRiAnxqoD0 ODk/ywfGXAmSwquP23SxXNQudk2vKJrvX6Rg1BM8lyCTVfS0GpvP/MxsR7G+g5xRTOl7Fp 5v/mQczHMkdp9enFrIEJcYGbjaB6EAA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688501472; a=rsa-sha256; cv=none; b=baH6HU20rSetNxOT2dT2PyMtchjNAuyklXFqx2pnNfzHp/juereB9ZS3CNL+EheLaM0ynW Mn3ShVv62EZSAkOQfJyy30qGgD1p4Hpy8DNNmPJOM+UfFnDo1byA5Fvk09LHaS2vD5Qptx OFr9GtdOwZ0MYM93hgXsgGIcYk6mcdc= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=hOdDIaFp; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-c5c03379a76so1370747276.1 for ; Tue, 04 Jul 2023 13:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688501471; x=1691093471; 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=yOjdvBOwTGuWn+yLARgRT5neCZ1ueI4UBq46eXgM3ng=; b=hOdDIaFpo4xtIzWTjfNid6BjkTQuSMurMO7nGvf92/ORBO3k6J4+RGHxAlY5tQ5STD o++0/Yx13ZapUQpn65hKGIk406kcfc3WGbEJGeemn2nTYhQYbsauwHboNPUQfv/V2es2 pDVUt7lsEF65r7Oc2EMHn1cnwf6mAcgDpKbuNV5ufN2EqGniqcdYx9csZ6lo4bEJa9uk f9mLa2nc2v+diYXv+LPzs0+3X4yg+bzEgP04IsetxXO4Q1jJ5DZUVKR/dAVOcavDYlAP C8TvrRtyEe4YGCdOo7kiA9mZe9CicJ0xA0N8ObF/wwBOop/6CPzP5YZgYvmdg8OyO/dd rlxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688501471; x=1691093471; 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=yOjdvBOwTGuWn+yLARgRT5neCZ1ueI4UBq46eXgM3ng=; b=RTRGXVIzzpqW/FkYsRk/WfLADfr0mQymXnPGdEbpvmrURJs1RABmgmmphq7IJ9TBmI fn6PQad8a90GOhv6Am98dN4n4+a8Ys42G4nv+7NvVSX7N8QUtWgJprYuPtpDRNh3Z68L DSqf9c5oq4zRSV6zU6pSmUTvvJ5ZZ6xQKJq9kluEDHZv+FoB/H9IA5yeGiRRPg8npqU2 6TzyDrhUqjxG37T/gKx/6BGr8tLOJwMXv6gv2qTCexvKR1XWBwxuU7PDsAbXKwO3RBy2 Mlv4kN8T21c4PfDslEL+QtHjczyLhV1wZycno+bV6zwsyGtOLKSV5sdRhgIvIFw+37z/ N8Gg== X-Gm-Message-State: ABy/qLYDAGnxQt+VSZtiSP0pMV9C/iiNGJh7GAiRFzbygkAIWeB+OJJj dIQHctGCYCFXUGMqGRGk8wGN3VUOVh9oHnvq80InPw== X-Google-Smtp-Source: APBJJlHrRkeP2QAG3fnTPSrm+dN9Rd6S9XqpkFNYkaOLBnMEzxIFFTJXFWxThDr9KXZyxb0YgywhaLT+DwYmu/XsiOM= X-Received: by 2002:a81:91c1:0:b0:56e:1df1:dc58 with SMTP id i184-20020a8191c1000000b0056e1df1dc58mr13670934ywg.45.1688501471172; Tue, 04 Jul 2023 13:11:11 -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> <3c042dcd-192e-7050-07f1-ce891b95dfca@redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 4 Jul 2023 13:10:59 -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: 5AFFB18001C X-Rspam-User: X-Stat-Signature: j1tdg38wnu7yq4oftqnibzzzo8g7dr1y X-Rspamd-Server: rspam03 X-HE-Tag: 1688501472-988712 X-HE-Meta: U2FsdGVkX1+bN/bv5ljJZ0A7/h+Yq2uJSYSFpVfPTCIDG+r+/K4XvwSXdyDoVko5mUaaNUszqB1i+ICV5vBfTY5TUjwLMnhvPtgjvuWis4+bXuGPDgKMKV4yVbil3W6xLSXmKHakasc+4PkEBPTBvtgtdk3ogZnmbFpgiMLd0/zSVDXPWDDQNlru4aQqalfVz/OC7Yv2MGHY6kV2KE91UVd00Vd/hnuMcH0VRx3HGPazhQVUtMTlXGi0k8EHcmQuy0NcdJ9RcHVOFNp9XhP3nH25zXjBmRP7Y/MHeDpvXwSW/Qz0T+62eYjGlFMORKymm/Aks52dbdtwtSd0sYOlxtflIerUsnzrSzG1t2sO/q9S1TVhoiWYM0jxSTlxCO+B67Pc0l6KUnE40jlO7+nPkdnm9T/6BJl1znF/oDx9nemXc5UvzmTrA6g92QGci24pXOn8vNTX+FhCyCzwA2EL+lkU4S8xmWQL7T8XI79ipe2W7hkyvypkqzI6x9aRByRsY8368yt7zUQMR91g5Bn7ZPRWcv6WFTCzCLTHFta8k5KaM1ylFwBfjeVcrV8IQYe9yCLNd5DC2nWl+XhyNm5DPfa77V4Zn/3Aw3aLVKwEQyBmzCnOSGT+XTNmhn+YN/EHy6ExjQ3c/4vsjAD56wNspSTcGLCv8zdNZmZx5KsSLYKHEEZjhawN8u7IUPXQji/ThgOOF4Fi83HiluVUODq5Mn5FedaWxeQlR7siK6dJXr3L79OV/9uaY3yc730eUv60DYa+47fhrvu5LamhQVgSGGsYSNTELTuByyyvdjvsvNfTUxY/otLpv2JP3jTqBQiFu39MQYd7IGKEoSqhs8gAmW2kjNBWXi9yZfilQBdcZrQJWf19F+qj0x5kUoWUuEoJX0JJD8dd8J/hOSxv8Bcd32r3MceL5r5gTcxXiSDpXlSVKMmJUC+fTyaVHmv18caeEl4pz1kbtUmWSNQJn+O yELd40FY GDRDEDMRyZGm/zZBRdlEa5lrVXSLVYGRazRE6Pf0+okcRrsxtocXNdGbA+W+Uhhm6Onjcvi/Uhv9H+8Q6yqrNHr+aF1Hr6MQiMqAREpZ4ZgcTq64r6VU4IFwc/0UhB2kH4iAHTa+E9Pa2RPJ8Xouu1qPHxMYIndZDnoxBiZRExHOGvlxkzonnOgiSlLmJ7sHOwsILYCdHnPTukc4AWY0k8pVLPhgZ7HImuUjdqfSu759EkQ3qCXyheIwggSjy/SPTz4dhLX/86DghownLrTkvD2eJa6NDTvLbaFeTrQaufM/vrc0SCp7m7nScyKBSjMLDZMUFTr+47lJcaLnCg8Fmm249DaWsN6KszdOYweyiagLy0GMyiBo8NYD2bAbvUvWVD/j1BNmj//iPD6/qGWz3WoAT+JwnYOyshsXKA+fd7zdbWTvPSWtgtj2hiKOlQtZGi6EGzkmViYT0/xSiMuAPHZD90nNDIjHHk4WMbBZ9OfgMlZklGwjBmY6j6aT+F1knhVEC X-Bogosity: Ham, tests=bogofilter, spamicity=0.000015, 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 12:11=E2=80=AFPM Suren Baghdasaryan wrote: > > On Tue, Jul 4, 2023 at 11:05=E2=80=AFAM David Hildenbrand wrote: > > > > On 04.07.23 19:56, Suren Baghdasaryan wrote: > > > 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 concur= rent to > > >>>>> fork(), on the yet unprocessed part. While that fixes the issue a= t 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 dange= r. > > >>>> 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 mu= ch 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-thread= ed > > >>> 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 m= ake > > >> 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 stabil= ized > > >> 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. > > Ok, average kernel compilation time almost did not change - 0.3% which > is well within noise levels. > My fork test which mmaps 10000 unmergeable vmas and does 5000 forks in > a tight loop shows regression of about 5%. The test was specifically > designed to reveal this regression. This does not seem too much to me > considering that it's unlikely some program would issue 5000 forks. > So, I think the numbers are not bad and I'll prepare the patch to add > VMA locking but will not add BROKEN dependency just yet. If someone is > using an old .config, they probably won't notice the regression and if > they do, the only thing they have to do is to disable > CONFIG_PER_VMA_LOCK. > Of course if we still get reports about memory corruption then I'll > add the BROKEN dependency to disable the feature even for old > .configs. Let me know if that plan does not work for some reason. The fix is posted at https://lore.kernel.org/all/20230704200656.2526715-1-surenb@google.com/ CC'ing stable for inclusion into 6.4.y stable branch. Folks who reported the problem, could you please test and verify the fix? Thanks, Suren. > Thanks, > Suren. > > > > > -- > > Cheers, > > > > David / dhildenb > >