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 40206C47258 for ; Wed, 31 Jan 2024 12:22:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8026B6B0080; Wed, 31 Jan 2024 07:22:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B2316B0081; Wed, 31 Jan 2024 07:22:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 679EF6B0083; Wed, 31 Jan 2024 07:22:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5844A6B0080 for ; Wed, 31 Jan 2024 07:22:25 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id F3355A0D0D for ; Wed, 31 Jan 2024 12:22:24 +0000 (UTC) X-FDA: 81739519008.02.5992017 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf13.hostedemail.com (Postfix) with ESMTP id F2A4A20015 for ; Wed, 31 Jan 2024 12:22:22 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of alexandru.elisei@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=alexandru.elisei@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706703743; a=rsa-sha256; cv=none; b=ImlK1/94YbADAaEpIEYzZ1OJJRKsjxbxN16BxO2DjEg1jkGsGY6O7D4SQD+peVfKDzrxB6 mCi5vcU9i5HkSgTz0KF5Cr+4qaRtcVSNAjbAhZTGEVbT5D/yHg09IZJQbQ6jOmQT4qUwjN F0Gd2r/joa6KGGWIS1npGUf9dR+jKPE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; spf=pass (imf13.hostedemail.com: domain of alexandru.elisei@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=alexandru.elisei@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706703743; 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; bh=ABFox6rRPIYyAXFl6faANmT7b+rplgUzQeKZ3q0wfLs=; b=R6+ak6T+w0/EWF6oEilndScbXWO1igs/0TRUVGARNADf+Vx6t8dug/11hb4OPhvhUtk9Ch Ji0I1ynlABk/1rIRj3Os11Y69FzCjw6x9drOit2YaJ3LkFdVHT2ln0bdy1LX9Sgjb0rAgK wOOPFX8HoOuMbPwjwvlm5/cBqFI+6fY= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 53ACFDA7; Wed, 31 Jan 2024 04:23:05 -0800 (PST) Received: from raptor (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4D3293F738; Wed, 31 Jan 2024 04:22:16 -0800 (PST) Date: Wed, 31 Jan 2024 12:22:05 +0000 From: Alexandru Elisei To: Anshuman Khandual Cc: catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, maz@kernel.org, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, arnd@arndb.de, akpm@linux-foundation.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, mhiramat@kernel.org, rppt@kernel.org, hughd@google.com, pcc@google.com, steven.price@arm.com, vincenzo.frascino@arm.com, david@redhat.com, eugenis@google.com, kcc@google.com, hyesoo.yu@samsung.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, linux-trace-kernel@vger.kernel.org Subject: Re: [PATCH RFC v3 11/35] mm: Allow an arch to hook into folio allocation when VMA is known Message-ID: References: <20240125164256.4147-1-alexandru.elisei@arm.com> <20240125164256.4147-12-alexandru.elisei@arm.com> <1e03aec4-705a-41b6-b258-0b8944d9dc0c@arm.com> <7612b843-cd31-4917-87c0-c26802c5bef2@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7612b843-cd31-4917-87c0-c26802c5bef2@arm.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: F2A4A20015 X-Stat-Signature: f1frubdok85a6dn91nqgoxk7tzjoftd9 X-HE-Tag: 1706703742-835704 X-HE-Meta: U2FsdGVkX1897DGNFx1Wd/4qdsM5+NdTJCHjBZXYfYw+xXeRng57x4k7V0DitQbV/mVCG2oeXbIdd5ZO++drDMccjxrvW4+YjUCQRCzRM5L+bCL/3BTXiZUge5s4x3u2olhFgMK0n3uwSfQ2ZiREqZciGAeg4840JMVuJeLfkCoaBXGPkKZcMqlFGZiHPK5z6v/9BhUWIpAvoLwUK/6umzyA154cdDPUceGAT7TqdVqaigHYgx63JoDCT/iXScykuTORIT+wXuIJQmYPot/4DEYeWWqyep2vxuRn9JxMTC7n/zWgdBU/ubM7yxQ31wegvfa2oSL6XWvuG+LRgzgv6k3rkHmZ+fEnURq8v2vTSY3TT0XlvP5blzk9JvNctAiJGdSyNAXjc23QLg15A5uyHwYpweUy6KnKcPZPGGrlLwhBB8ngZiDRBgqqoSTtmcd4bjzr5VdWrJvnokQ4SGQ76BSVJcIG4qSuYOovgbIU9oCaxb5q8GQyTSROf8zqOJMv8ehRjklMbSRhtFp46spFKQeb3vCrgDBfwDRxxlY0zqw1czI5/Af1Zas6mP5bwGWEh4ityvsc/gcK/Hsc9SSYg68bQiDPU2oRCvlsboAmvblbU+IxoA9fp0m3yHaNlne+7QzWgM0UJ5dCW4AsIHI1Evvy89tFJU6mMjUS0nxD+B77CN6a6YwVEkbcPIgM5spSulV1FMQC45eaxO94DVX+GRgNOPAPfo2D37j1FLmRxKtGwy+Bkc/063mbZULPdhTAjFjz7EMS0OfWq1yYW1wsFbG+vgo3qqXBnkX7dIXJLB5y1jjjJLiIMFQK4sFyfuf5jBZ9xKaMTUqW0D+6x/Ej3SujLLNZ4a+YnTr5UEQ7uTAMj+PHAXKPg/UubC1u+0pqbHT3Wcu426trXbAkDLY+5q4TPasHLWYG7+TOyDswdrJEtoXiKdAzKNxcYEJ3ZWL3fF4z9nr3HX5kb+Ds0mN m/61hh6E ZlvmTs/0v5xmG4yA2/Dnf/v4rUSSbhuQXNxDcW6rAPhD5vD2Lk4WrttnXq1gdrOU5L94Jl25DcNNX11h89oKr9W+DUMfrbRpd8iIcuKclaBaJ3rU= 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: Hi, On Wed, Jan 31, 2024 at 12:23:51PM +0530, Anshuman Khandual wrote: > > > On 1/30/24 17:04, Alexandru Elisei wrote: > > Hi, > > > > On Tue, Jan 30, 2024 at 03:25:20PM +0530, Anshuman Khandual wrote: > >> > >> On 1/25/24 22:12, Alexandru Elisei wrote: > >>> arm64 uses VM_HIGH_ARCH_0 and VM_HIGH_ARCH_1 for enabling MTE for a VMA. > >>> When VM_HIGH_ARCH_0, which arm64 renames to VM_MTE, is set for a VMA, and > >>> the gfp flag __GFP_ZERO is present, the __GFP_ZEROTAGS gfp flag also gets > >>> set in vma_alloc_zeroed_movable_folio(). > >>> > >>> Expand this to be more generic by adding an arch hook that modifes the gfp > >>> flags for an allocation when the VMA is known. > >>> > >>> Note that __GFP_ZEROTAGS is ignored by the page allocator unless __GFP_ZERO > >>> is also set; from that point of view, the current behaviour is unchanged, > >>> even though the arm64 flag is set in more places. When arm64 will have > >>> support to reuse the tag storage for data allocation, the uses of the > >>> __GFP_ZEROTAGS flag will be expanded to instruct the page allocator to try > >>> to reserve the corresponding tag storage for the pages being allocated. > >> Right but how will pushing __GFP_ZEROTAGS addition into gfp_t flags further > >> down via a new arch call back i.e arch_calc_vma_gfp() while still maintaining > >> (vma->vm_flags & VM_MTE) conditionality improve the current scenario. Because > > I'm afraid I don't follow you. > > I was just asking whether the overall scope of __GFP_ZEROTAGS flag is being > increased to cover more core MM paths through this patch. I think you have > already answered that below. > > > > >> the page allocator could have still analyzed alloc flags for __GFP_ZEROTAGS > >> for any additional stuff. > >> > >> OR this just adds some new core MM paths to get __GFP_ZEROTAGS which was not > >> the case earlier via this call back. > > Before this patch: vma_alloc_zeroed_movable_folio() sets __GFP_ZEROTAGS. > > After this patch: vma_alloc_folio() sets __GFP_ZEROTAGS. > > Understood. > > > > > This patch is about adding __GFP_ZEROTAGS for more callers. > > Right, I guess that is the real motivation for this patch. But just wondering > does this cover all possible anon fault paths for converting given vma_flag's > VM_MTE flag into page alloc flag __GFP_ZEROTAGS ? Aren't there any other file > besides (mm/shmem.c) which needs to be changed to include arch_calc_vma_gfp() ? My thoughts exactly. I went through most of the fault handling code, and from the code I read, all the allocation were executed with vma_alloc_folio() or by shmem. That's not to say there's no scope for improvment, there definitely is, but since having __GFP_ZEROTAGS isn't necessary for correctness (but it's very useful for performance, since it can avoid a page fault and a page migration) and this series is an RFC I settled on changing only the above, since KVM support for dynamic tag storage also benefits from this change. The series is very big already, I wanted to settle on an approach that is acceptable for upstreaming before thinking too much about performance. Thanks, Alex