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 E879ED7879A for ; Thu, 21 Nov 2024 17:05:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E7F26B0085; Thu, 21 Nov 2024 12:05:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 770986B0088; Thu, 21 Nov 2024 12:05:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EAAD6B0089; Thu, 21 Nov 2024 12:05:36 -0500 (EST) 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 39B646B0085 for ; Thu, 21 Nov 2024 12:05:36 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C9D3E1413FA for ; Thu, 21 Nov 2024 17:05:35 +0000 (UTC) X-FDA: 82810725942.01.309E21F Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) by imf13.hostedemail.com (Postfix) with ESMTP id 46D5B20017 for ; Thu, 21 Nov 2024 17:04:36 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BLottUle; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of surenb@google.com designates 209.85.160.177 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=1732208547; 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=FbzeelOTslR/KHrOgwW0t93Zwe+09I3fmH31n/QNlAQ=; b=lZj0ABYXbynJ2oa58xvU5e0OdvpjVNKtMBCKWuFMtBD//9YRENt6QHjPVFrMgFnMCPxIht 712r+Lt5kpTVsvQt+rNt9kmSAgiJcbRKS/P+gyvTD77Tdnr4bCpPiRElhC3b2IoYflrNrM VKlkcqhZh/9lrpF1pMwgwg5PzQsJIU4= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BLottUle; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf13.hostedemail.com: domain of surenb@google.com designates 209.85.160.177 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732208547; a=rsa-sha256; cv=none; b=ODfD/O9JLHvqDwMIX523D7iBAZYFjXpyRU0B5gNlz/bAGz/wOXnrx7ED0tGd/N5c4zqYFj n42abh3gaJ2ZrtTzFkxnwBdFitK1qMVKYWAsnBKaufHiep0Wuyyb2RlFv5EX633PodheH4 X/dgdjiTm7uEtUsCFDnvjOnQATKpamQ= Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-460969c49f2so345661cf.0 for ; Thu, 21 Nov 2024 09:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732208733; x=1732813533; 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=FbzeelOTslR/KHrOgwW0t93Zwe+09I3fmH31n/QNlAQ=; b=BLottUleiZSpEF+1ZkCnXeBBeul3i1siugMDYN1VxVBx6H+U9ou9uLKeZUmhUzsjjg DL8q15jWMAW1DF4FelaUt1+k24e4MbxprzTk2HJlyliu8jCxBsIOfrRSOvRDJG0AJox6 0MWl6ELRdchTJg/cZ33Ya9NiTepnf6YE7OqgaXDX1oAmP2zkKO45VkaRmtzvXq2MU45D 322trZavHiDkz3Pi+Qqwvv9NT1ssjcLtF4Vm6ficeEAzpgwSeLXcAq06V5vesf42WBGk hUm8U8yURiImc/AtTAWynUBFkztLoJQgaVTRmJzaKfB6Nbl2sbaQbdBhxQ5AZA2Okzp/ kdWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732208733; x=1732813533; 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=FbzeelOTslR/KHrOgwW0t93Zwe+09I3fmH31n/QNlAQ=; b=UgDlTepWdqFyiO0eQY8oqpXuNL311VplFKCYM17Z3YRC/LetKkwlve/Aw8BJQJqgGS M4kaQrVe8BL1M/aWlu2wUaPUaCnKsC6YHdg0ZvpgMgXJG94P4KiXJNJMGbqz3h2Brhpn 4FbRk/EE2bdgNjk5hFuXXl49SAx+RoxT3jI7cJuQU3avhC5bNzuc+X1xUGWq5l2s9PBS UAlGH9r/c6qpM1K2hO+B6C2wwSq9nD7zIepdTwB3xXEbBbfrNCIHSE/d43g6LfKfoQwn AlsTXVyzQPeWqMfIhLk2LhSlyaWbqnuz8x5arGpya/W+YEem8Yp0B7BE2FP4m5lHC9IO aCCQ== X-Forwarded-Encrypted: i=1; AJvYcCVZdlpQsp/Fqo1cK9sWCm1ltqYJzdluDDOylKgPK/X8d6VOaiu2DLeXbC2EbQf3IMo4VXAyRBFKiA==@kvack.org X-Gm-Message-State: AOJu0YxuZ9KbNiKXlcsjRDHMqu0V0I89NJWKSbGNRnwxu4YRYytkPtbV QbAlQL0Y2upAsAcdW7u/ugd79JkIdfPEq6jCmsjEqzsSH1LMnFQHmjemnimLGO0On60hfsxTaqq uVMwb26KySmD2BfD9ZmmXE0LnOaMslofzTCR7 X-Gm-Gg: ASbGncsK40PvZAFMJC8zHH4w8UWJ8cZIHUiz6DsNZ8AUA5lIIuOqDqQ1JYnNbjVp3Gb JlXmCmRPHxj6ntuMkMqO+cJPy21TJ2TArjZpZrqrGJ2ubwTDBCw/JXn9BLDBL X-Google-Smtp-Source: AGHT+IEmxC31siYh0URWSvBOXH/D6mpJAtcWIEuMEukulOsxIf+33rCEYQo9mERxz5BBpt3yaGO4a9w2aMpXBv0P0VU= X-Received: by 2002:a05:622a:30b:b0:461:6832:8805 with SMTP id d75a77b69052e-4653bcdcf41mr342011cf.12.1732208732479; Thu, 21 Nov 2024 09:05:32 -0800 (PST) MIME-Version: 1.0 References: <20241120000826.335387-1-surenb@google.com> <20241120000826.335387-3-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Thu, 21 Nov 2024 09:05:21 -0800 Message-ID: Subject: Re: [PATCH v4 2/5] mm: move per-vma lock into vm_area_struct To: Shakeel Butt Cc: akpm@linux-foundation.org, willy@infradead.org, liam.howlett@oracle.com, lorenzo.stoakes@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, souravpanda@google.com, pasha.tatashin@soleen.com, corbet@lwn.net, linux-doc@vger.kernel.org, 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-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 46D5B20017 X-Stat-Signature: ihx4abmrca3qemknnm5bfukys18qibrs X-Rspam-User: X-HE-Tag: 1732208676-734759 X-HE-Meta: U2FsdGVkX19ndyLS7ldQ35ZOpDem8zc+Q+fZoQwDVoJMCEpzwOAkT8n2qxJmbr4hFbJgO6+PeQZ8MkcudYT6gumrDfmFd0+Ts7KQ8GJm1IhoFlcCV8MD7N22imvI7oG4yNiNe+BHDjwcvdOOLUhRoIDPWJvSglAxR8wbr5KM7f11Gy0RVLJGrWZ/TVKUkgqY3UofQica6sl1DYuBDWbJ6ZcxlRdKheTno+fWC3K7XvC8ZAXf1YJqitzj4PT4X65CcqV+9TjEwLUsO7G7q4uZVmHVSRmKVN5IfR9pukcMEibeWcgT92shQWZ+YzeyXY+qvNxIk/iYFWAIFcwzkfCcoZN8GFYABh+Lkf030MRodafX70uynTCXEKsYWsaGqzNIhiXbe8jB5r0rNLnb6Y2ckhSqaXH4r9kjaVJ3MLJUOJAg3jNkCgXYIaB4JjXCJte6pPCr8SePqb7Wuylv3HtPwZV5+OKywS3AW6MuA0HiKI/81t8K6jGFLKJz7TIFi257rKfQWBBzcSeVhV8etIBKDxO8qmhMEX5NpYZlQRP+YXQeKrNoHsFxV8K6EP0U2wwfmVKG/9wfz09oSikEVlW83Jmx1dY79yScv9FWYRk9ryJeYv8uN35kuvmoc7TzIdJaTe6PeDfSKxMreHxB2blFta8uyrTmLVh4I4vqccJ0XkTlZ72w/ECBEA5dtsfUxKSqrCq0zLhqxVLR/X9YDdu6wdHrKX01ntjzF0i+QM2EV5tCbGOFWzWOlW6fMbm2SyvfoyLOXgfjJIPgmwWcHEuiiSP98Q0sa3+2rlc8Q0O6N4uybYNGOyMPgQKgPmEnztHAUOrKNSSagRCpjKkjIIXhcrgvXg7YVB+81jyuPS9ysnc+1Fi/4mEdsyThhlQfelneK6lfaMNRE9H6gkMN+sZUyEqu3teOdS4PzreKTnHyqLJQnPnUEv+i5xRSEKbWuC/FgGns4+hMvvQWCpkZpiN 7f3KLckK Xzu3TEzS6A1TneGYw6hWFlU5ar4vTXXtExdrs/MEmDJEW9UsJPjS0I81I6qfJ5i5JOpEMcPNLe0/FZoUdSxKtw75xGeRBOFg/gpDhFybiV8HL62BrqfKbXrAwNz/0PBOLuly1pczl2ZgRwQuSDDkb1tIPVp12n1Q/e+6y8elJ+NshbxxTwpxt3mFKlCh/Vvfz1rngHCM0RvZJTqzVQ5itMULb1FhKBbj1cAUWK7FmbYQut37A6WcCd6mNiytK4Bf6R7BzvNDz93BBUz9IVCsqwdih1cCXy9JxdkbP 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: List-Subscribe: List-Unsubscribe: On Wed, Nov 20, 2024 at 11:02=E2=80=AFPM Shakeel Butt wrote: > > On Wed, Nov 20, 2024 at 04:33:37PM -0800, Suren Baghdasaryan wrote: > [...] > > > > > > > > > > Do we just want 'struct vm_area_struct' to be cacheline aligned o= r do we > > > > > want 'struct vma_lock vm_lock' to be on a separate cacheline as w= ell? > > > > > > > > We want both to minimize cacheline sharing. > > > > > > > > > > For later, you will need to add a pad after vm_lock as well, so any > > > future addition will not share the cacheline with vm_lock. I would do > > > something like below. This is a nit and can be done later. > > > > > > diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h > > > index 7654c766cbe2..5cc4fff163a0 100644 > > > --- a/include/linux/mm_types.h > > > +++ b/include/linux/mm_types.h > > > @@ -751,10 +751,12 @@ struct vm_area_struct { > > > #endif > > > struct vm_userfaultfd_ctx vm_userfaultfd_ctx; > > > #ifdef CONFIG_PER_VMA_LOCK > > > + CACHELINE_PADDING(__pad1__); > > > /* Unstable RCU readers are allowed to read this. */ > > > - struct vma_lock vm_lock ____cacheline_aligned_in_smp; > > > + struct vma_lock vm_lock; > > > + CACHELINE_PADDING(__pad2__); > > > #endif > > > -} __randomize_layout; > > > +} __randomize_layout ____cacheline_aligned_in_smp; > > > > I thought SLAB_HWCACHE_ALIGN for vm_area_cachep added in this patch > > would have the same result, no? > > > > SLAB_HWCACHE_ALIGN is more about the slub allocator allocating cache > aligned memory. It does not say anything about the internals of the > struct for which the kmem_cache is being created. The > ____cacheline_aligned_in_smp tag in your patch made sure that the field > vm_lock will be put in a new cacheline and there can be a hole between > vm_lock and the previous field if the previous field is not ending at > the cacheline boundary. Please note that if you add a new field after > vm_lock (without cacheline alignment tag), it will be on the same > cacheline as vm_lock. So, your code is achieving the vm_lock on its own > cacheline goal but vm_lock being the only field on that cacheline is not > being achieved. Sorry, I should have been more clear. It's ok if some fields which are rarely accessed in the pagefault path are placed in the same cacheling with vm_lock. In fact I've done that to pack them better in the previous version of this patchset here: https://lore.kernel.org/all/20241111205506.3404479-5-surenb@google.com/ (removed for now based on the feedback). So, vm_lock being the only field on the cacheline is not my goal. After this patchset I'm planning to try packing the members better and save some memory. >