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 7A8D1E77197 for ; Thu, 9 Jan 2025 11:51:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0FB286B0082; Thu, 9 Jan 2025 06:51:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0ABEF6B0083; Thu, 9 Jan 2025 06:51:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDC006B0085; Thu, 9 Jan 2025 06:51:56 -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 D0E676B0082 for ; Thu, 9 Jan 2025 06:51:56 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 78F6BB0F83 for ; Thu, 9 Jan 2025 11:51:56 +0000 (UTC) X-FDA: 82987749432.23.8B4B16E Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by imf18.hostedemail.com (Postfix) with ESMTP id 108111C0010 for ; Thu, 9 Jan 2025 11:51:53 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=X5hC5ARD; spf=none (imf18.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736423514; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zbUr2ORaIkJpc84p9F8I0++Zs6AuCLIK/hoxp0neO8w=; b=IqNr0lMaToRJjcdgtN/nXPptEGZlezIi/awhQASmgaMHObZ5wssWmARVLyLiD54E1AlqIY T5GNExV2sgLdgiaCXBuEvp0W4jOPXiHGOui38SCbpAcdDTXuayt7pnHaSigCgeIREtwY4E pNB47NWe7H+F6nUtOM7naHISo9hKXmE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b=X5hC5ARD; spf=none (imf18.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736423514; a=rsa-sha256; cv=none; b=hV+epRaSxh5B/G7aadeWDybhfCVxZ5Iip3r3iMPPJ4Q9ABFNdjWOoWae6o/2alKVHxTPhS Ane6cDPspBS0tHmphUEktZLjQea+MASeJOctoFY7P7n6VBJGfhe08nMVxYqNP2Fv8bL/EF tv871axh8ET1XapkVk+cuzqdS+LTYPw= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=zbUr2ORaIkJpc84p9F8I0++Zs6AuCLIK/hoxp0neO8w=; b=X5hC5ARDFM6hCrKId9Q/HqW+K4 7HSaIZ0W2LopxKSDeNw23xMgiMCfXQK021md811KZ6Z1fXMHa8DIxIcAgqtZP/cm2IsXXa4Q5FEz+ Wl/0+MF604bc+7Y+3NbG7bjPQ0ul2GXanmG0m0TVGsn5re3Pm4B8oMMXawhNIaR3BFo5TNNmIDTSb SfM6FrmSoZhvgqyttixVHymdaUyRTWvEWBFcVQH0MXhVc8lP2MJX46OTapPbJiaiMqsq6hzdbU5uG NzVyaJqHWWYQUPL/mATs1Wvqe8tQgFagpKucaB8B75rQ3xMIE5vfpiPTdGynvFjewQkgkmuhFPj9D TB06am8Q==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tVr4h-00000009YkZ-0su6; Thu, 09 Jan 2025 11:51:43 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id C705B30057A; Thu, 9 Jan 2025 12:51:42 +0100 (CET) Date: Thu, 9 Jan 2025 12:51:42 +0100 From: Peter Zijlstra To: Suren Baghdasaryan 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, lokeshgidra@google.com, minchan@google.com, jannh@google.com, shakeel.butt@linux.dev, souravpanda@google.com, pasha.tatashin@soleen.com, klarasmodin@gmail.com, richard.weiyang@gmail.com, corbet@lwn.net, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@android.com Subject: Re: [PATCH v8 00/16] move per-vma lock into vm_area_struct Message-ID: <20250109115142.GC2981@noisy.programming.kicks-ass.net> References: <20250109023025.2242447-1-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250109023025.2242447-1-surenb@google.com> X-Rspamd-Server: rspam05 X-Stat-Signature: nfoytu8kefnxjhyako6wa43i73sdiapp X-Rspamd-Queue-Id: 108111C0010 X-Rspam-User: X-HE-Tag: 1736423513-132839 X-HE-Meta: U2FsdGVkX1857n9rYmonpUMiNyBp9KjqEsESRdsffkkyy515yPvYr2MNgd+szuVGu8tx4QUReYWthXiHAtRv94rD7M2QuueXLYEZecqPJLTQ8ofgITph/zRbpLjq4XFQct+puYmOnt4jk7ZUYAvTZxlL8WQONjddeifgNzud74czMsezFnrdTzq+Rl9aIBPTlC7l1W2nL80+DkRnFBaBk49PBdzPny1GHR+4s3HGZjDa5d7a1YopSYO/3ELwZPxu/93A1p34oNaHZarV1A/A/654QlTiFDhlHKWrsQExX5OD41t3hhtzgojHVisioVJIRFMu6wOfV311EagE8vL0SG+bQ33udcXT/wyLxxupjatutGAEpjXrrZW2GabqLHpMJjFCaMNkU82xqCVzHHHthCjVLsY4sVotUTlxT6n0zdaLGVPXlfipTawSOjFi7UvlmH0dfPO8jYQ4oV4FrDJflmggBVWPDiZ4wLIdLz5XGPJJi+c+Ov84+DwaTSu/m3A335/9NtIvMgRui+ViwYB2W7rmri1x0EF2RqJSHvb00z5p0gpmU9swlJYFl070gGMrjq7Bxa3ryNwLV+x6MLf8euZ4EfobkTeG7L4aDLHrX5hHm0ib+HxtRLzSrHFNOW4Twt8kRmN3f1e3pb+zx97Fcxmmds87z9OuV8Ags+QC2QlqLERaKDopfPJKsPI8Y+vsVpBSmuoGw2wG/dFuos/PySv6AsB+VlhEzDDHfJmtNMaqsfEcu0bwUfp08W+cfTuWjIBz+36RjIN11xY8j3daqlLYEjzo9NagytBujv6yontTDtcbyfWmqPYEuf3AcnGH1w+yc9wr1UaL89U8AJhpR03HZEHinasUEMEW2YtwlC8u9uic6mDfpH3b7ACN2XljgE8ui74phmOYqLQWXE6bZE2w35MCe2OQGpRYI6+auTFI2n/o6HZGQYC07flMaTp728ikNPsS9FcYqYscynM i4oigJ+k 8Q6CjhR1Ly9mPSkDLX30HdUvQUGjS72GDxUU72gyBW9mQiOKrKJboZuZltPnsLEROin+uxAZ2qwR1r1zcbz3kTii6wi3GoJloo9YT1tqZoDVkGNXG+t+LGY5tChezj1dsmfDwTj8D080dWLnpV8rr4uRwi9TH67c7uHEn9uiyqLDqhCOgkujyk2Q44awFQpy5GzmlorKloiYcljZ0bFyaT4Zk8pThb2tPt/xXmmVHb2KKsf+Hk3/A/oH5liXzmElv6P6wnf4NQYHeiU+Av2DqtAlBbGf2+6d6XXAaqcd34tIe1gU3jkKNWJTzcQ== 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, Jan 08, 2025 at 06:30:09PM -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 and > even there it can be mitigated by disabling adjacent cacheline > prefetching, see [3]. > Splitting single logical structure into multiple ones leads to more > complicated management, extra pointer dereferences and overall less > maintainable code. When that split-away part is a lock, it complicates > things even further. With no performance benefits, there are no reasons > for this split. Merging the vm_lock back into vm_area_struct also allows > vm_area_struct to use SLAB_TYPESAFE_BY_RCU later in this patchset. > This patchset: > 1. moves vm_lock back into vm_area_struct, aligning it at the cacheline > boundary and changing the cache to be cacheline-aligned to minimize > cacheline sharing; > 2. changes vm_area_struct initialization to mark new vma as detached until > it is inserted into vma tree; > 3. replaces vm_lock and vma->detached flag with a reference counter; > 4. changes vm_area_struct cache to SLAB_TYPESAFE_BY_RCU to allow for their > reuse and to minimize call_rcu() calls. Does not clean up that reattach nonsense :-(