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 956C5D743EF for ; Wed, 20 Nov 2024 23:33:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EEC956B007B; Wed, 20 Nov 2024 18:33:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E9C746B0083; Wed, 20 Nov 2024 18:33:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8AAC6B0085; Wed, 20 Nov 2024 18:33:06 -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 BB7C66B007B for ; Wed, 20 Nov 2024 18:33:06 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4DEB7160D0D for ; Wed, 20 Nov 2024 23:33:06 +0000 (UTC) X-FDA: 82808074776.26.3716714 Received: from out-178.mta1.migadu.com (out-178.mta1.migadu.com [95.215.58.178]) by imf01.hostedemail.com (Postfix) with ESMTP id 1A27E4000D for ; Wed, 20 Nov 2024 23:32:23 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=cwHUpPG1; spf=pass (imf01.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.178 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732145381; 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=ZUJ4vT4Ev2xEsGw1E2zk4jxanqmeSvQ/TmbjsSxUcJ0=; b=pq/8UXt4d+GZhqzRvwR+sywLVcshOwwcAR7S/QTgnnD1rE2jBSIHsfIrtuKMhXESFaoPX3 MInoDz1O0scdfA9agm6sVROBpwOrqDABJNylnoWh/aMqbFu8BiI+jtm1gCQARRjrJhZwCm GQmD4cXV+uI4/jJhwUY5Fey1rMISDJg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=cwHUpPG1; spf=pass (imf01.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.178 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732145381; a=rsa-sha256; cv=none; b=B9/15Q2Ywy7Mf3Tu1wuItTC1EKUtMw6sB5HUPmyYQ2JNnslOj81lRgQMKjpzPT+uVMnAX7 pmPLB/3km9VmXvwv0aLYTo16WKSxynw5TDUvv05G4RO9oIgkmLCG0DBPfA5qwKP1Pxm2nn eZbyOzworeAu2Mvvhg3WrEzJtHBYraM= Date: Wed, 20 Nov 2024 15:32:53 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1732145582; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ZUJ4vT4Ev2xEsGw1E2zk4jxanqmeSvQ/TmbjsSxUcJ0=; b=cwHUpPG1lD+rR862ml7ejaG6HIZPrb7H8/Bly23BzEXpadR1vB/Wtz7fXKfzBDBfsQ9nHu ph9b85ad81NHJB2VGmxsLJ/LxEKub1yy/xUBd/A8AZEMoE2dMLfA+cxhMpTiCA5HSahm8E aAKDh/v9vs6/E2GX4719ks7ZONEiHfw= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt 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, 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 Subject: Re: [PATCH v4 2/5] mm: move per-vma lock into vm_area_struct Message-ID: References: <20241120000826.335387-1-surenb@google.com> <20241120000826.335387-3-surenb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241120000826.335387-3-surenb@google.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 1A27E4000D X-Stat-Signature: e5oano1rmz7rwwjb5xbkujx7dqimi6yp X-Rspam-User: X-HE-Tag: 1732145543-942693 X-HE-Meta: U2FsdGVkX1/+mH39ZJjS3BMljtxS6qlHsbWvDO/areGYVx97w09sh3tVaFa59YTRZX4RNL2jmEPTH/UVhUhXqgAspqEWBEwRtz11ggpdzbMD+jVq/SDD4jaNp6Qk75Zpt3lKMF+1hFBASvHOk7mWJPZmGYV9Y0kxOGe9/LTDFbll1Dc3KCqyAwXNjypwMim3Z5hsBRh1rq/6/xtmL5YtFx6IY9/Bl+T/4CQclIQFREF0gkzjNzmg71bkcu5mg1ZzOwfHMQjSm9Zrf0P5OuZRqFM2of8qVhCZxolJfb7b8cpLVydNdnijkD7nSPT09SlscVuoqr2NlnzQULW+jNaavFK1Qu8imyG5j4xHkcaJyPTVN6Z5eR5QfitX6BeX44Nauq86IDn3sCSlAB9smtYXgj6PpnMvLFRhpCLSiXbxQvoROGqAWsJ4tHmFHRtXJ4I+DKRNc2rrvWcHIYcMKPU644DU34v/wMU/tTVqpD6YqXZWyZRPVqj2JpVl8OTHF9Knn+9D5NEdnly7kehmy5lZ4jbqEW4H7jSgYdFua62y3xrYiAnQmQat9JVHqn3vT3qbrt8TfcSpoIOacv+ZYRsP3S2gs14GnC+9CUxCEDyxU5ZJr9SOjw/lVs3+n4FUFgEJ77g1H3B/qXW/0bEKfjw+CbMzxaY47alaZ/exBsUpwOPDdeIGJLAX9Fsz/20RxykavKKbwvVKgpbEcxBuiRsu/bhDn5HgLWE1I+tmE5UmrZGQrQhQgT3IBpkzrpxxmeCSugHjyzLPXWNefv0xRulOUR98p2ypqecUujB1ZBPKXZ5KYuJIUV+m/ybP42wj3dXKfmZLQ6sFwq2/aQ5UG38npjt+h0xivR9a2F8gsqN4GjH82HVPL+IL097zYZP4YzA1rlCBDaZQ70Y/b/smUyX95w+iYnTINXojjrxDX64SDRQqUZp3pNi+nKynjsH/WK80qrVnqFBP33UfGuVUuVl 8yHGBW3S 2M1jiOHComD0/U45C+uYFcJfL8Vc5gmQKb7Q/+ffsS6pCB7VfNnOuqryhbHl1gTRqPaOFhK18uccU57xELtTtf/5AqPrJaIL6m5N/s1UZ/iAqpTIXKzLT5aDnchQcZOF/Xvh6Pc3VkoFTleofNX+IgkDA0tR8VfURIHbLWikhMm7mXlg8BHkSnFd3QhsCZPOQqA+ycJMAg2b8yYiMa0enayWNWaAHYIsW17sZRLrY6jwJAqNae2yv/MOUPfLS9is+cfhmXg6dTnfcljk4JrMhRaXk76aG1oTS3eAg 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 Tue, Nov 19, 2024 at 04:08:23PM -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. > Move vm_lock back into vm_area_struct, aligning it at the cacheline > boundary and changing the cache to be cacheline-aligned as well. > With kernel compiled using defconfig, this causes VMA memory consumption > to grow from 160 (vm_area_struct) + 40 (vm_lock) bytes to 256 bytes: > > slabinfo before: > ... : ... > vma_lock ... 40 102 1 : ... > vm_area_struct ... 160 51 2 : ... > > slabinfo after moving vm_lock: > ... : ... > vm_area_struct ... 256 32 2 : ... > > Aggregate VMA memory consumption per 1000 VMAs grows from 50 to 64 pages, > which is 5.5MB per 100000 VMAs. Note that the size of this structure is > dependent on the kernel configuration and typically the original size is > higher than 160 bytes. Therefore these calculations are close to the > worst case scenario. A more realistic vm_area_struct usage before this > change is: > > ... : ... > vma_lock ... 40 102 1 : ... > vm_area_struct ... 176 46 2 : ... > > Aggregate VMA memory consumption per 1000 VMAs grows from 54 to 64 pages, > which is 3.9MB per 100000 VMAs. > This memory consumption growth can be addressed later by optimizing the > vm_lock. > > [1] https://lore.kernel.org/all/20230227173632.3292573-34-surenb@google.com/ > [2] https://lore.kernel.org/all/ZsQyI%2F087V34JoIt@xsang-OptiPlex-9020/ > [3] https://lore.kernel.org/all/CAJuCfpEisU8Lfe96AYJDZ+OM4NoPmnw9bP53cT_kbfP_pR+-2g@mail.gmail.com/ > > Signed-off-by: Suren Baghdasaryan > Reviewed-by: Lorenzo Stoakes Reviewed-by: Shakeel Butt One question below. > --- a/include/linux/mm_types.h > +++ b/include/linux/mm_types.h > @@ -716,8 +716,6 @@ struct vm_area_struct { > * slowpath. > */ > unsigned int vm_lock_seq; > - /* Unstable RCU readers are allowed to read this. */ > - struct vma_lock *vm_lock; > #endif > > /* > @@ -770,6 +768,10 @@ struct vm_area_struct { > struct vma_numab_state *numab_state; /* NUMA Balancing state */ > #endif > struct vm_userfaultfd_ctx vm_userfaultfd_ctx; > +#ifdef CONFIG_PER_VMA_LOCK > + /* Unstable RCU readers are allowed to read this. */ > + struct vma_lock vm_lock ____cacheline_aligned_in_smp; > +#endif > } __randomize_layout; Do we just want 'struct vm_area_struct' to be cacheline aligned or do we want 'struct vma_lock vm_lock' to be on a separate cacheline as well?