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 B1DB9EB64DA for ; Thu, 6 Jul 2023 00:32:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3823B8D0002; Wed, 5 Jul 2023 20:32:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3327F8D0001; Wed, 5 Jul 2023 20:32:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 222C98D0002; Wed, 5 Jul 2023 20:32:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 12E9C8D0001 for ; Wed, 5 Jul 2023 20:32:24 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D3A1A1A0559 for ; Thu, 6 Jul 2023 00:32:23 +0000 (UTC) X-FDA: 80979310566.20.EB03651 Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf28.hostedemail.com (Postfix) with ESMTP id 17AE0C0010 for ; Thu, 6 Jul 2023 00:32:21 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=eBJaGFvC; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.219.182 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=1688603542; 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=b059XCxsCkOrU4O3JPVlTW246Y1hW5JtDs6f+L57Wmg=; b=Eh/mDZh3VsmuiriXVufQfFNv69PGcUS29VOlQ5nbfi4No1VSzw8FkH9yGCU+3HUiq0BJ76 CW0H9BIaAcDzIW0x7n+IGmHJZSqiu7/U1OrlUbXSPOrngSqhAWxMFf0attBP7s9A8dLi2J 4wpEbAW6OpOBZ4v8BPnGL4moH2Z0C9k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688603542; a=rsa-sha256; cv=none; b=W/uYfHtDvJl4947yvJ3qHQ0CYq6jxakKfGRZeXk5Rlt+6mzUiD5+nqK3WzU7kjOMTVQJ1P gvJWAsc9aWZvFlYfvx72wmv6vi2Allg7BWgVzh0deG56OljgY6jVQ3bUnljiHjbLmIb2Dl nmAw30/attofqNqUWiEznJGG1T9V0P0= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=eBJaGFvC; spf=pass (imf28.hostedemail.com: domain of surenb@google.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-c6833e6e326so77870276.1 for ; Wed, 05 Jul 2023 17:32:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1688603541; x=1691195541; 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=b059XCxsCkOrU4O3JPVlTW246Y1hW5JtDs6f+L57Wmg=; b=eBJaGFvCWu50szMQtD2V3lIYr0va0vgg0MD9I0V4Uy05PtsBkeUnpLMEFo70l0fwdT mI2CCzX1FSskABvJuTKkMgjos4w6uGIC5T+YFH1guzJ3/CCfkvjIXMPA1h52s6iXMVLi z7pbJ/wkC5/1tTHrQ17hZufbpJq3ayPXMQ4Ik9Uo/slagtEWh8mpS0NlLqy8uKlV8Q+o 90+kaYx1od2lBMTCbD6+iQ4Z6JhbrViiALSqlRNV6+wwqVlPSZFLvoLg7J6RTgSQ94oW 7rZXx+2X2uhdv4wa0HvlXSDqCaJ/XNnIJw+9cW+NBwEIZyc2l3fBzn+gotMNL/UFc1ee jJ1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688603541; x=1691195541; 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=b059XCxsCkOrU4O3JPVlTW246Y1hW5JtDs6f+L57Wmg=; b=jBsHd3nY8u0h5B0K+35jZj9jBcDLQluYYmYd/cdVf1n6ntEKueW1ImMhszJ98nZ1+s sxIpvZjQrLIN3xd+fjt9ZmHSzuWuMqUdocaIpRqwzjJEvL0Sf+hCJAT295yuEIcTwso1 81j/uTaSUkVZho8+e7YC6ZgkNZZwfnLol+tE+TPfkSvZHN2zi9trws5hmE6jHJiAMmv+ tZdNINSlaY0ZmHRJ7SDIkEfz7trhV8XaiRmaHoNNazWdjZC970aqBmEbi0qpp8rsD5r9 f9cI/RQzMJD4eFzqtdvKmHdAwwUuUx1e4Uie09cA2ql+MF8MqIUCX4Bzrxk4ZTvV0oo3 HqDw== X-Gm-Message-State: ABy/qLZW+jL1ez8qWsh+41UFjLNNlsXJk7TlC+htIYUiRPHbxUa0nZOg XxZMXGAXh4iEDPNPBHqvQANGO3hFbBAkHgPbuSizIg== X-Google-Smtp-Source: APBJJlExs/sClZhmqN+LrYffIQ4a3G+fZe5JH4iqdSm6PJE+juvPYAodhwhw38hs723ulwsxVKeT+DDgwx1UICga0eM= X-Received: by 2002:a25:fa11:0:b0:bd4:c299:a80a with SMTP id b17-20020a25fa11000000b00bd4c299a80amr438121ybe.10.1688603541038; Wed, 05 Jul 2023 17:32:21 -0700 (PDT) MIME-Version: 1.0 References: <20230705171213.2843068-1-surenb@google.com> <20230705171213.2843068-3-surenb@google.com> <3cdaa7d4-1293-3806-05ce-6b7fc4382458@redhat.com> <20230705172424.e505f5013bfdf44543d9c6be@linux-foundation.org> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 5 Jul 2023 17:32:09 -0700 Message-ID: Subject: Re: [PATCH v3 2/2] mm: disable CONFIG_PER_VMA_LOCK until its fixed To: Andrew Morton Cc: Peter Xu , David Hildenbrand , jirislaby@kernel.org, jacobly.alt@gmail.com, holger@applied-asynchrony.com, hdegoede@redhat.com, michel@lespinasse.org, jglisse@google.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mgorman@techsingularity.net, dave@stgolabs.net, willy@infradead.org, 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, 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, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 17AE0C0010 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 9bzy7rdsp4hi6o1i5tzus9otunekk9ex X-HE-Tag: 1688603541-478868 X-HE-Meta: U2FsdGVkX19xauX3gny3YTI8/XyAcNBtchIfaqv/BKouvnPiD/xQE4DOrV4wNgE/1MFtfKl6Zm5qNECxHbYfJW1JNgAWsql282fvAxvbewtbwQiME+GpK9UB8gLtxnTNkTgflao0JPYda6OhPSpq7imoWsITP7xKoV8ZMZVAhDarfUBB2bAUjnMuSy+P+cuzkCh7hvT3j8j0lj0tq0i66IXpuJcy6QvNIwSGRE85z2e0WLoi6yAxw3wRj70ITZh8vKFUhWff3Ab4WNP+jib+JFkP1Eoxq/yIB6jb5+G4KLAAg3FRKJcDD0sgonwujdPfFeB37JP1BXAa7psxb2/hTI+aTzhsxPuzmnls2dYZKobHpBSEFfaEmlGFbymIHx1GY30w6rM7Pxt+CGtMGXD9yX4i6KKEnnOgTiysh+FCeQl3+W1tp7HJRt0kp13gxSPFCYpo3P98GncdSB99fq1R/BCzG9tPodL7VN+MDAVinOsWA5vswVexT4JdPskA2Wgvy3s5sfLlZY6tyZ1GbZFqmDD+Q8ZP+V3VG8y+vHszX5a4x57JTUjSWBuKBM5NSDqTKEfVWR3rO2/V/4h8Mukh74TlRCWnV6/5BrUn2RkaeuT7T/6G5zPkjL8hyhY/JMlv+dP24jXXhymIxaj4vPxqyVnjzRTQFcjjKdpVkmX+lc5BamXalP3g+ihAXNF8cFbSgm8QibV79p9gQ8UPYOlVpILvtxz/hG3VVnvG4m+oq/USXsreCsKQvnVeSNm7hX8bfmYksNqANjp23Vfs+sbhZWGKExZodjalWbFY+hRU9llY/lsspbw/VVxoQBXAdx3oWyboqDjeZcZ5JOgq2OAhx2oWKr/GQfLXyoay3cO4OL/07jIIg96NqQkK+QRo1zAcd+MKXArK9zv1RBvoluNUEMpZWw1cPv2KQcGZAJwNckb16nLz0INC9zMT5GfHK89D9yti17kuJYYCdB9RcU9 v1pgB/in vIOrpnsMkiLxxdMR9lQYid2Tu7swpy+EPZvLnskgb9jF0plU+HE8REs0kThf3M/zeR5Vuhd/TY3vpO1W/rH+FGWqPzcHoxtzoyTPtMm1YrQalNfe33JXqDS54NZi8XZ9AIdL3rA5RJ5lsXBBaNTOos3ittLdOa3IMwLk6k5/HvaUOQ4CU535YSlx5KsV4HlxSf+G1762AdFmklIQFoXQ5yDIOH49Uycgjsoj+th3gqT9+IVrXVAa7rrb2vMFbdjTbfuDTn+xFeFYtkWBj2lDALFOpnfPhZh+Xam5o4DjGSJnYJ0hwT+m2Lr4FNCaBaQtKamq3PjxS3iNpSiU7kHb/8JWfkZvC0NinVJ6cQKohq/4qEDdmz9Gw0obefC8QLkugmmEUoGkM+LUAIc54rn7kw62s8LUdxc0JPYIGhWQiG1yt9P95/wI+5msKT8M9et8e9a7tVeQh9R+TiH8= 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 Wed, Jul 5, 2023 at 5:30=E2=80=AFPM Suren Baghdasaryan wrote: > > On Wed, Jul 5, 2023 at 5:24=E2=80=AFPM Andrew Morton wrote: > > > > On Wed, 5 Jul 2023 13:33:26 -0700 Suren Baghdasaryan wrote: > > > > > I was hoping we could re-enable VMA locks in 6.4 once we get more > > > confirmations that the problem is gone. Is that not possible once the > > > BROKEN dependency is merged? > > > > I think "no". By doing this we're effectively backporting a minor > > performance optimization, which isn't a thing we'd normally do. > > In that case, maybe for 6.4 we send the fix and only disable it by > default without marking BROKEN? That way we still have a way to enable > it if desired? I'm preparing the next version with Liam's corrections. If the above option I suggested is acceptable I can send a modified second patch which would not have BROKEN dependency. > > >