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 7216EC48285 for ; Wed, 31 Jan 2024 06:54:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0C0456B0075; Wed, 31 Jan 2024 01:54:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0712C6B0078; Wed, 31 Jan 2024 01:54:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA1146B007D; Wed, 31 Jan 2024 01:54:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D86526B0075 for ; Wed, 31 Jan 2024 01:54:10 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 7DCC814049D for ; Wed, 31 Jan 2024 06:54:10 +0000 (UTC) X-FDA: 81738691860.13.0417AF7 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf24.hostedemail.com (Postfix) with ESMTP id 5CA3218001D for ; Wed, 31 Jan 2024 06:54:08 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@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=1706684048; 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; bh=ss1y9GNNTn2GBVotEtC1Hwo0eWV73qboNMjT1J3hjr8=; b=mpUA6F3lapP/4VKTMywYnGUApuwYlGXz1Tc1GsVl/bv9mmbwixd6HkyzkPKQjTDEA5tn6g UYIKCjZb4+PWJ5wDIYtZvBdQrHk6HirQD5f9sVg50jKfAL5yZ7xIGuAFDV1PA4q27oyM5X 6f0ButlJsJ/503lFmbxta4V6Wy88yJM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706684048; a=rsa-sha256; cv=none; b=dO6Y9eAqBP8rQzGziAu6JeLnylicFc2yL6PnHdCVh02oDY2xf9HcKGv89PgfeCkAzkNw85 EAutZIvc4j5ei3flGsUodHi9ch9h0LYERSImfxDxHwU16NnImbzRKvayx7yTlxr3ZEF8X+ tok5fl5E3KqhdG4nis1VqNwcPc7DwMU= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com 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 C3D5ADA7; Tue, 30 Jan 2024 22:54:50 -0800 (PST) Received: from [10.163.41.195] (unknown [10.163.41.195]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EE9C73F5A1; Tue, 30 Jan 2024 22:53:53 -0800 (PST) Message-ID: <7612b843-cd31-4917-87c0-c26802c5bef2@arm.com> Date: Wed, 31 Jan 2024 12:23:51 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC v3 11/35] mm: Allow an arch to hook into folio allocation when VMA is known Content-Language: en-US To: Alexandru Elisei 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 References: <20240125164256.4147-1-alexandru.elisei@arm.com> <20240125164256.4147-12-alexandru.elisei@arm.com> <1e03aec4-705a-41b6-b258-0b8944d9dc0c@arm.com> From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 5CA3218001D X-Rspam-User: X-Stat-Signature: h7ohk743kgp7fpe5z5tfajxe7571tjzs X-Rspamd-Server: rspam03 X-HE-Tag: 1706684048-357247 X-HE-Meta: U2FsdGVkX1/p7v+NLIGQbqkQVBlkaTQp3wLgJET6rd8E2fdxtcLDWcLLjuEy2ZNkPxlXqcvlDjKdRf00SOmLLqFwo5wp3/I8CZvQODb56JOribji5IV827MZS6lfu/LhVg/AziZfKqHo8yTVNdGaeuJjXoKxPVh0i4+HfcGutpUV+wURCu1FuVfgPZg+EmqXO7VEfwCcmdX3qbccs6xZ16rb/g92omGlzjQKRAUUL/SgI6ihQHY7Ov+L1nmeOZtRPyPb2Nh0/od5aM1SQjjZ2Hap2u6RS6mte+sWV1dM6Fozs8WCs/dNGNHEdevf7vJn2emrRaQYyd2K3rSkfrPRHMaZ7DTo1UHogO/h6Ho02JdktJdAhGzPIJ5sTwqOFemilLwDNXnn5kuZLPjN4siTC1gVuEaN7xr2krAP0xS1Rq4ROGpCRPHov0qM8FQ+JrTRTIPNe6xTB9OOPQZpXS2DkrgWaBGKl8W4OEzcqnY5PGTVsIiHk2tS8Kiznx4/lTzCfWMFCxnvbFrzLhyq/XP7yomI3LI/VmGa2j6pmyGQdYfhXI3EJ9+BsFPFv8b0Tl+5yhy/B+kIh2KyWqJzoh6Mklcz81Y+psvdweVN2r1T/exqpL2oAhW0NPOCEXjIhGFZ3J6GosDX9ZfiqI4G1gIshyLNR9DoC/PeHYSkUjvpSQQGvTWxCPFHiJEPybBnb3K2PJF6BUTdwYEkYnygKbsAL+KZZJ1NGtbqoD5Vv9BH0y2CRn8SYqDbYV7muHh5CGHzTG75IYzVKumFNREhRUBjU2ufnWtrb/nJzdkYV4IixXBzigOAnTz12l8Cnlh3PSPqT8VEKNNWHSKFuWfICmdqBvGFf+6566ywyTHXCSBThkqpoE4GBiKy+ONMuzFvRaoj1mntMl9eiyy5q+eAeI6WvFcIkDaevwwSLqcwmzy9EwPg+LUd8bzj4wqbHhU20VZe13uAd3F1f1R0rlp8DFl wso2lEBB cn8RwevpmXSHeNnTuZzBillMgjrElidXyy+hDuq1Xqwg8/wt42POQmKYo+urwhWWq2R5dyzbycGvmQg6a3kJS435Q5y51tZt/jKZiEx6KVDdwjtdv31Erzk/ufCDzPi2hAEMWO6O8YR0dO3+81d+zc89DiQ== 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 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() ?