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 5B172D462C5 for ; Wed, 13 Nov 2024 15:45:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF07E8D000A; Wed, 13 Nov 2024 10:45:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B78808D0001; Wed, 13 Nov 2024 10:45:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9F2908D000A; Wed, 13 Nov 2024 10:45:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7CE628D0001 for ; Wed, 13 Nov 2024 10:45:36 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3BB89A0B36 for ; Wed, 13 Nov 2024 15:45:36 +0000 (UTC) X-FDA: 82781494866.27.DBCCEC8 Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf03.hostedemail.com (Postfix) with ESMTP id 91A9320013 for ; Wed, 13 Nov 2024 15:45:14 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=c9OH9l9+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 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=1731512646; 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=y9LcAqJQLCHBtE4PTnGvwVOmtzNtUb5KN/Kd4UQbnZw=; b=p3TdtFTeA1B0dajUSOdZCj08hsZy0Hw7+gadZpQUPSL5PVNspqZZoLYtM6V1A9UHUYZsnk itLgKgIOTlGqqRNw9HMGOaq5Su2+T8qgO9Mq+z5VxvNq5WQlkKlRcvIX3jnUWuCVHKjNXg aFtEDQr+svk+CCxvdKqOYL6x5LKfr/E= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=c9OH9l9+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf03.hostedemail.com: domain of surenb@google.com designates 209.85.160.176 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731512646; a=rsa-sha256; cv=none; b=mexk1Ta6dBrlR9xHB05ibvxR8dh/sZdI5kitByv5s36jH75aMU3Pf7PaR2bzOz6VaCxyJR sP+rmElGGJiuW/0u2uGscsNiRjGSRSuIbaSgSUDk1va7DSfC9ExjmggTMBmmkbgotTIa8/ NqZLR9yymgn1e5xrezkVmqiZCG585wg= Received: by mail-qt1-f176.google.com with SMTP id d75a77b69052e-460969c49f2so301891cf.0 for ; Wed, 13 Nov 2024 07:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1731512733; x=1732117533; darn=kvack.org; 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=y9LcAqJQLCHBtE4PTnGvwVOmtzNtUb5KN/Kd4UQbnZw=; b=c9OH9l9+TEDOlsKZxHetfZ4NfYFkw5wdex1Yd0raYrPF6v4Lk9Y+MDhqwBsiXoAz8S M4+XSKmIXtj28tFpzwE+m9VduSMOQODR4SGkUoBPXjpOIM4ZeHZb952EKSWDwGpFU9Ux sjm6WoDziQoibk5LylqiKBuhfnpDHhkw73JbXZutPMtIVNMfWRNRygYzpDuHsfRR8KUx RqqGAXkYVaz2g4cAIMRYq2NyFtCkjMBT5M1b/EUR3xShA3ChvsxC4gZTwzl1XIVIRVKn jkzPuJvrxzl4XBBe07H7hhEQomLB+aBZI5Qvxfr/6XDdwcOUE53tgW0npQmgTI6POEAo 5yUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731512733; x=1732117533; 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=y9LcAqJQLCHBtE4PTnGvwVOmtzNtUb5KN/Kd4UQbnZw=; b=n1JIzZZLvpSX086mFn3IBZ2V2145zSa9BwfCSIDrFKDxMoGnn16wo05wJtALPVITlM nd9QBr/ctQYMG2rgGmV3Vm4xgImQZTBi//RsMckM3uqyr1HGk4jCyZKxA5I5Xx19zAIY GQLuyDiH7LM2yefLOwLcU4JacPOn911bGYafXXEJoLOUsMQMq2MWnVEwFyTphR1KHm+h wooVZTIlPOs66Uk7qXkGjJRUMAUQGdRmN8D33tqaNhIXkHKnApMWIJIyjhGBNX8L7O0z F9YKj2/5JE7WASDJulWOd0ai6FvNLe4LIyldvs2XdR3yLq1QHG/15GsZj7xyjovMozjo jvwg== X-Forwarded-Encrypted: i=1; AJvYcCVD+wsdpkGEcytdhvskFwVyPnF+ie3O0FPmTFTJ2iOirW7C0P+id+R5k/4uMDBMe+mhwvZTjTSnCg==@kvack.org X-Gm-Message-State: AOJu0YzACqZLZO7fc8nVwYnmAq2IcmT8YulfY/t0GU1SpxI4FEU+nCAx HkEqBuWDkzK10wFvqfyyJTFsma+vjrBHUjtQzR5D/NkD7PzQ6stU7vW4QU4ChMLhZ3LPCQxxZLD qy5Cf5DUMkJbbt5fa4TrbCR+Q1MBPo6ItHTYj X-Gm-Gg: ASbGncsGdoa6k4l8uI5T4nsWiabx4tXZDUT4fUUJXO5Wj04e3pecL5RQCiwFq6Q51xi MtQq1CeRDMZukiMvmV6utfIxHbYi672I= X-Google-Smtp-Source: AGHT+IEU50ssIRkLH4v8of+m3tqCQvKnSi3e7I6ibXMiHACUohVg9DGIX6dJ3TtfEcYenzYEZtiSpyNteI9xWnXGsuI= X-Received: by 2002:ac8:6716:0:b0:463:53bf:19c0 with SMTP id d75a77b69052e-46353bf1db6mr945271cf.11.1731512733108; Wed, 13 Nov 2024 07:45:33 -0800 (PST) MIME-Version: 1.0 References: <20241112194635.444146-1-surenb@google.com> <20241112194635.444146-3-surenb@google.com> <637370b8-3e3e-4457-81d6-5913a3ff1d4e@lucifer.local> <5d34da83-92eb-4666-816c-73a0e831aa89@lucifer.local> In-Reply-To: <5d34da83-92eb-4666-816c-73a0e831aa89@lucifer.local> From: Suren Baghdasaryan Date: Wed, 13 Nov 2024 07:45:21 -0800 Message-ID: Subject: Re: [PATCH v2 2/5] mm: move per-vma lock into vm_area_struct To: Lorenzo Stoakes Cc: akpm@linux-foundation.org, willy@infradead.org, liam.howlett@oracle.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, mjguzik@gmail.com, oliver.sang@intel.com, mgorman@techsingularity.net, david@redhat.com, peterx@redhat.com, oleg@redhat.com, dave@stgolabs.net, paulmck@kernel.org, brauner@kernel.org, dhowells@redhat.com, hdanton@sina.com, hughd@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 91A9320013 X-Stat-Signature: w66w1n143z467ecaczfe4i7r5zty6s67 X-HE-Tag: 1731512714-593869 X-HE-Meta: U2FsdGVkX194I8mVXrfK3215e1kSN0kUSuo2zUWCjI+xkMmu6mEv0hvYb5Srxht3+XbsDuZFZ9zHEDuEQaOSjFJN8CZ4fq9FtvryQR+1MMI/TkfYhQn6Ml2KFahhAprDkdaSoD9tI1FGBYvuC6BPxU/R9lYUOzpQ7DCJN6jx3y+MGBsATlkVUem/BJbt31ohlnKaCaMU/DIsDod+tnzJc3sQe2QZzvwjR/w3o6EUHcuY8U+3nyw6m8Vjjw59pCj/bC3fUbTZbUPeTEDEIpUh16hOzCsiSAkHJdU20v7rA2ZQBjxWVHAQiDWmeXtMzpOQJvkol/7em5RuzNn76203/1xJhs8sdJDGRrQF+Wd8dFEd+bTCd6CC1tOUU7jUQ3Zc18UnvwrcHrLrJwwKC2OIB0rCyAasJgit7ppLZONsAwUuCKZ7CtqWKHsol2F9DKnz8g4B4nvI+cGBiflEH1wEM3YUXStMZPk7sLryEQEWmqxXbZaM7FBAgkUMsfGsGBqQHBhCxSOzAUAxScpeGvfriA+370YNGg0vDxzzEyZWgVWTF3Cvk3iM/MPgpa4+K9SCRABXW5mZZmxdY/YHjZ1D5bnhi3tkCMsdN1IFmJpt9tDJZPhRtnF3g7XW0+tHZz9ApzLlz+vXOrcI1qGdCSUalIgSNq0623rPUPdcqeNLf+mC7F+zHACQml+6nOx64XZpD10ia7DatQ1Tob/w3TqIiYx9srA+3bSuuur2XbyzQIBiUwx+4g83uQxe84fGg8JOYRBs/o1B9ri+Cf7t45KwfsSSyB8+p10yGkTQLGK3DyqcVJVLFYGq0BSRAXVeOVpsoo0vEZdWSLk/jFiAfrySNZU9TVjulnNpy8MblyTxRHWwx7rWSkjTN4BOX361hUq4SzQN98c+rngZqbfO0nH/VFyRu8ARPnmE7i3fo/UKxKFdrrFfY7YwrUj1B82S720fMuN5SjILJ24nzg9s3+5 RyEMn/g6 DRjcWmRmMaYE00BrjQdeEoIQproHxZW4ZRr35z53eiieYvX+vlU1tTKpm3VOowpKCkoYsPcQl2leurTpkm3TxhUuv8fy3VwdllSchWL7N4PYhP0PbK/mxFQchjXejOGS1Yfsb0uG4bEizM+tExb7cLhLPzaVPLY9JBoxoCuyfD/WLxIF2rJdHihmX9b6RT5f0wRTsoOditiXja71Su+jcKqE+x1lG9lmDkIbQxFgBzC5PpYMIm7Gg0l9z/jjA+4++cfuDRFiMOKd8bZ4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000081, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Nov 13, 2024 at 7:02=E2=80=AFAM Lorenzo Stoakes wrote: > > On Wed, Nov 13, 2024 at 02:28:16PM +0000, Lorenzo Stoakes wrote: > > On Tue, Nov 12, 2024 at 11:46:32AM -0800, Suren Baghdasaryan wrote: > > > Back when per-vma locks were introduces, vm_lock was moved out of > > > vm_area_struct in [1] because of the performance regression caused by > > > false cacheline sharing. Recent investigation [2] revealed that the > > > regressions is limited to a rather old Broadwell microarchitecture an= d > > > even there it can be mitigated by disabling adjacent cacheline > > > prefetching, see [3]. > > > > I don't see a motivating reason as to why we want to do this? We increa= se > > memory usage here which is not good, but later lock optimisation mitiga= tes > > it, but why wouldn't we just do the lock optimisations and use less mem= ory > > overall? > > I worded this badly. To clarify: > > I don't see a motivating reason _in the commit message_ as to why we want > to do this. > > I am certain there are, in fact Mateusz and Vlastimil have provided them. > > So my review is - let's just put these there :) Yeah, I had trouble wording all the reasons because in my head it was simply "the right thing to do". Now with all your input my job has become much easier :) Thanks folks!