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 A8958D462BD for ; Wed, 13 Nov 2024 14:54:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 392F76B00BB; Wed, 13 Nov 2024 09:54:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 343FA6B00C1; Wed, 13 Nov 2024 09:54:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E5C66B00C2; Wed, 13 Nov 2024 09:54:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id EFA6D6B00BB for ; Wed, 13 Nov 2024 09:54:13 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 75C77C0AE8 for ; Wed, 13 Nov 2024 14:54:13 +0000 (UTC) X-FDA: 82781364960.07.0C711F4 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf18.hostedemail.com (Postfix) with ESMTP id 72D281C0012 for ; Wed, 13 Nov 2024 14:53:52 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CGa1Qw1f; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731509564; 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=cPsqq3GsgW5QLtdw2wIeuLt0KF0vtG6d+ArqDrwNOtQ=; b=FNwDgId/bmwtjAFgACJZ2gHfQ5oH+9RSHMnzcmk4W0j+1thcxdWm5mQOgecOI65ysVmx+m 0xwXK1zW2TF0PK8VTsQy7yCc7sut/caY2o1wOD2GrNfEPpiMKT5qrI44EBrcmSRy/eihRZ dn9DcvGkzREG982xFXdtcoR1TUDP3Do= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CGa1Qw1f; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=mjguzik@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731509564; a=rsa-sha256; cv=none; b=gCAQo4OPTe33WJGyosHGjDrH7MOKfO2qundlst3P0FDjuZXuijACXlPKTHh5/lyYNMQev9 +N2LK01LAfzRT6bFirG76m0kBUI1PAbauCO7xo96Wuv4Ps5+XTwRffOvZKka+2zam8/lAf 3i1uQa01DKB2QqEAkVkQwyw/ud2XRv4= Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2fb4af0b6beso97340881fa.3 for ; Wed, 13 Nov 2024 06:54:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731509650; x=1732114450; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=cPsqq3GsgW5QLtdw2wIeuLt0KF0vtG6d+ArqDrwNOtQ=; b=CGa1Qw1f4UWcmbFlqVPoK69WMY9BvYlwOzuiBnstaL1XUswGZVoW89A0BpBD7IwQ/G Rosizh44DiEoPJ98oOlrGp7tWr+72ZYbSZpsqWtbxCmMQQeb7MBUKPennaHTO7dV5UDi tLJKEU89XVIMwTTg4ymgZyM96VUxAtbS00ZFpJkyOvfCUp3wXjqar30jrSy7/1tSx45T HwwHXaIm2bq9axLcciQdcmJP28yzTdfpHvbAF8DHzlqRLYFjDhr+2dy0Pzq/GTop1KUE 7Q6mK+0Xx45rW7+z1k9mpcxGGbECk7NYjxfNbJUQozcXH8iAZNS6rsujRBkxb248+aM0 0Dag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731509650; x=1732114450; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cPsqq3GsgW5QLtdw2wIeuLt0KF0vtG6d+ArqDrwNOtQ=; b=xMtKnb9SEtvHNTRu+XX1dMoQ+2z3+ILIiIgn/Gb1Wt40LvymM/yyuG6NQdKf7W/45p +UbdfMiNN+A9zGVaQBdGxtgnkaMe9qMb/JWJZ2ocTOf5BLoZWDhrRDTVhlYRHiMDffPm 9Dr6N5wmpN5eIXdv/M0gqmR4zJBvfo3+AU+TMIdMvz3bOZ6r0qBH8olwIosVsjytFqm6 pWbdLpn0iuW4G9FN38CRoOb+9DQQMx29/ny9CZuL/+giMVj1WnQTaC10eJ/xqC6Q+tp6 b0SLA98MdfUc35f1p5sdRAEFVV2tbjeW8ElT6abVi0fRCecRxzH+u1Tr68HU65ilDsG1 APyg== X-Forwarded-Encrypted: i=1; AJvYcCW94/BB9ciXqsQAET66fRQfN917r/vThGaWk1lEfVNi1d0tJRV9cnIfEE4r0f8BSt7o8bb+nojA/A==@kvack.org X-Gm-Message-State: AOJu0Yw+g9Sv4K0Fy9+ABDIV3+0o0+Dx4wJpqZkQ3E9MfyskWQHhkqm5 4GnX2oXHKDdHK3smArxWCvNCo/jWHKiIzn5j2p6krArf6QIlMRsK X-Google-Smtp-Source: AGHT+IFyJLrsSDJUOCNHFogeMgexCMp5IS+HXBgXMCDqPwZeB+ErCgI7Ol9mjj8/kWudvB2qEEyAeQ== X-Received: by 2002:a05:651c:554:b0:2fb:4f8e:efd with SMTP id 38308e7fff4ca-2ff2028a97amr155476111fa.32.1731509649214; Wed, 13 Nov 2024 06:54:09 -0800 (PST) Received: from f (cst-prg-85-239.cust.vodafone.cz. [46.135.85.239]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9ee0a4b5f1sm893784266b.60.2024.11.13.06.54.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Nov 2024 06:54:08 -0800 (PST) Date: Wed, 13 Nov 2024 15:53:54 +0100 From: Mateusz Guzik To: Lorenzo Stoakes Cc: Suren Baghdasaryan , akpm@linux-foundation.org, willy@infradead.org, liam.howlett@oracle.com, mhocko@suse.com, vbabka@suse.cz, hannes@cmpxchg.org, 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 Subject: Re: [PATCH v2 2/5] mm: move per-vma lock into vm_area_struct Message-ID: References: <20241112194635.444146-1-surenb@google.com> <20241112194635.444146-3-surenb@google.com> <637370b8-3e3e-4457-81d6-5913a3ff1d4e@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <637370b8-3e3e-4457-81d6-5913a3ff1d4e@lucifer.local> X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 72D281C0012 X-Stat-Signature: 8br7tesqf3owrqaggdposf4qgy1u9dsr X-HE-Tag: 1731509632-603366 X-HE-Meta: U2FsdGVkX1+ZXf0iFuQahHuLT6IrG1+Lf1MGQ3vkKZZ1+oq3mHRulHgxLTC+F4pvvQmPj+ZSkq/Tc5cDLkkzOb4liC5OSkcIHmzvlXOicdZiaGP2vGf0JnzJID5LdTkduVazL8D80czO2Kt026zs2LXSNJpnGNUCAATctmxO5qPuXmPH4BFqLCh0aWx50dxJ6/Q6tqwYnsYqc2JVLF3t4Pny7hZBhuSLbbtmZiHOxDEbp9r9PErIPUVTfX5wwRbf+fpnzjpQkdVr+fH3BXf0sZo8rdivIOs+bHhTWBMafbs3TyvkJTcmuNA9kbCQZq+rKeqPXzEh4baxUtMpUotoPwaiHGNnVhHRDVlPByY6/nYCkoqLLlWPevlsBLweXBIg6sZjN1XWRwcbxGOGnD3VWEe16D3WfvaD3dxlYxt0D+LI2oY9CGWIXQKdpBWEcX37Wl1gYxaKenFRo0feQXyIMb0xtiMyRhQPDiX78ceUndXrh+VaRL86rL4GOwS9u3zTAGGCX8y1w/swsQ2Oj8uyaq4fyIBZnJIsS9MIrdhG+HhKVOQ5kWolMiYrNNngB2C4hZTtwRtTRaCtgh/wzBkOWc3Bbhtot0oSkf8trTMyFDblQCbeY1dnfRqb8A3jH2rGNLndORjquMv2XWgKUikZ3gDPO6muqfjBXmM9MmlMn6h2qef9kjZjs5dmk1LrYMGO5c0OyJqZagSm10aqBg/X/Zzqja7PgwLGxlefKch/VaFYaINW+wZFGDaW/ql02KRryllbtFdhD7UzOl4CidIRKyyo6irU93V/d3g6HnkSIzikTzXOdYM+b0r/ac1fqHYJsMFTHNVipJIykJ9TBbxXeSx4C9RCC4Ucal9f3+QFuA+kWiR6LLZvvzsMrc+y/+kYy97syj5vrKfF0h1k11W6fJ7f1lrXJPwPoykb40eES+7hvG6akeBf926UXo5FWdXg2O9GCfJBC90NXx6BDH9 tCoC+25v jxIjUvzhuEw7Za+98xX384EUiEaOQru7Xpv1KqQJfCyNSwXV9X8/sDrRw+LsRoLDjDnl2G9cOnlh2OBdY+oEgAC0X9VbyB5oG50D3ZJHPw8D7tE6nObgCfXOEjdHxmKKeZJQLJq6++7B28sLDePnkZNKLofPCEOba1HutYJ/ygzj7As8Kg5mpydnh8J82IRB3e87PD3c2Gjk4LxfLSVqOqvz5xkjBKxghing8ndwtl2ctSll5+gSS25UEZJVrSlT5xJJ3rNfw5uxhnI/bcdxVKMPddp35fFxjpssVsBVz3PUVJhCavE1FkB9PrxVDcaa6wkOEZqlhlTGtq6zqLWWVOGnuWoo7Zm+fjb+/0gZ/yPi2+NlN5NghmGfDVD8uI3gCrYPZCN9uZc26VkAW28DfuW2BnmY/ZzXAlYB8pq3zqxgow6fBmEWFlTktLd4I/EdybPjF X-Bogosity: Ham, tests=bogofilter, spamicity=0.000170, 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 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 and > > 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 increase > memory usage here which is not good, but later lock optimisation mitigates > it, but why wouldn't we just do the lock optimisations and use less memory > overall? > Where would you put the lock in that case though? With the patchset it sticks with the affected vma, so no false-sharing woes concerning other instances of the same struct. If you make them separately allocated and packed, they false-share between different vmas using them (in fact this is currently happening). If you make sure to pad them, that's 64 bytes per obj, majority of which is empty space.