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 4B4F6C25B67 for ; Fri, 27 Oct 2023 11:04:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B64E66B03C7; Fri, 27 Oct 2023 07:04:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B15216B03C8; Fri, 27 Oct 2023 07:04:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A2B6E6B03C9; Fri, 27 Oct 2023 07:04:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 942ED6B03C7 for ; Fri, 27 Oct 2023 07:04:46 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6B9BD1CBC44 for ; Fri, 27 Oct 2023 11:04:46 +0000 (UTC) X-FDA: 81390958572.04.2CAB7B0 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf20.hostedemail.com (Postfix) with ESMTP id B55761C0008 for ; Fri, 27 Oct 2023 11:04:44 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698404684; 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=wMx9sKaQM/7ovV6rHitfpBGjjOE4TkCfc/2u4YcH1cg=; b=fKqCNHEBoHXDL55me9afBq8wGFAk33iXt9vjbDGL3HnQ85r807OfAU5xxU+Yb1mlJ7RtsB ouAFeQ+4/8hNqW6dZfnpYULLwQWMxaKxI6wIhn0I5qOgcpFIv/nUJ5HpRfhyj2Y/kkz+Jc hXE+7yEk6eFb0L8emLUhFsh2Owxs6PA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698404684; a=rsa-sha256; cv=none; b=lIi7nYMZZtnSp7P0s87kCgjGXRJl89/s4+fq17M5WiFQjZQ/mO/grerhYVbs1OxTDqhyiY otevViCDEYnplbvhwQZHfsPEv9TbISG360ayKfENMCsC0lI2uJUIjmoy5IE8cwe7AkfEpY 8bddeLoRUhSIc67rrMPgwCzjDH59HaM= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of cmarinas@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 82F9FB80BA4; Fri, 27 Oct 2023 11:04:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CAC0C433C8; Fri, 27 Oct 2023 11:04:35 +0000 (UTC) Date: Fri, 27 Oct 2023 12:04:33 +0100 From: Catalin Marinas To: Hyesoo Yu Cc: Alexandru Elisei , David Hildenbrand , 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, anshuman.khandual@arm.com, vincenzo.frascino@arm.com, eugenis@google.com, kcc@google.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 00/37] Add support for arm64 MTE dynamic tag storage reuse Message-ID: References: <0b9c122a-c05a-b3df-c69f-85f520294adc@redhat.com> <0cc8a118-2522-f666-5bcc-af06263fd352@redhat.com> <20231025025932.GA3953138@tiffany> <20231025085258.GA1355131@tiffany> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231025085258.GA1355131@tiffany> X-Rspamd-Queue-Id: B55761C0008 X-Rspam-User: X-Stat-Signature: po77opwopxgd6ftk1oerryw76jwgjoao X-Rspamd-Server: rspam03 X-HE-Tag: 1698404684-75537 X-HE-Meta: U2FsdGVkX1895Q/PJ5XNHSjXku8p4nCndqLJ13kpuHJczbPnwwGuUR1sJks+3uKSrqFw5ALicAQyFB2xAjtpTDaKGJc5Jt2v83U281ctT9lyq0ScgOmuBVPWDrKoY3f53SSeTyd9XHJPsyrzAEtD2EO2/fDuhIKR1w7VLgKXLSr8ywTl+GeJAPN39VHodBBwAEguMGZ1SHWUl30eAHVDjkhxSYU44HUINLy+W9OsYpuPEjOuKO6rUqCXe3fz8Jl7iNzbnG6S3R2gbAac2vFGJgFZogbL9F69qZtGtYMlxeKSIiEqIbqQVYlcXQBnWR/THK6ju0b6mKUZTMPV9F7x4jToNIZsed7S9S6aqo8NffcQhqra987pzObDmdz9pnBPxEtdlMoQ2PXi2Ui1N2rLbe4lBEWjpm7x7RXEJrV3qHgYqx1bwpOTSKh3b/Fl/kKXsjwXRWO3L5Vla/uhvxxdELRHhsj2nuaZD+tVtOP1ZJdUE6Gv7oeVgrTK5VkykVf1Iw56RpkZO8Tz3PC44zcw2iXzEOwffr7HIvfZm0U7tmaB4SU2aKvAMIdLc066hyG2yysSWxXNJylSD52D5WCYmq5JCHjmirZQcRQFIzndCFDJfrobUvhaQgXopEezf1c2cS2vjV8XkFgehBN4EF2NxugvyY58kjKo+8GMSd0TI72got1dEflXFIO0KRk0eEVvOCahDHK0hc84b8c4AiF8JAYpBmhaQsqg/8rMwUkadHizarNBoJ3HYZQhNPlXnsZLa+88LloC7i36zGmobNu10YSbZW3hdcEjBcX9O5xoVa3ZtTBV3IyoRvX0od1pnQ9SFoTy0BNbgqpOsEepF0xjGhPwwKAUWOV0nGt8VlqZaz5NxPULPaBndaYtzNVucerFTL6Pp5ybdmn2bd5w6Y/zcEfC2m0tahs9T3xj38QdDHdDwOqNVAli6vCcW3bYv6waeHlkSH+/MlhCEzY5bDw 3NkbpRwI HmctPcOv//KmgXTq/dAT8ZcLKWiPIaSIkKA5Qv2L/O9u+zN8tWNTcRONXnGU4cssI807Gk0TIMkfSD+vqS1DKNy5lP85vK/jbAcAb00OR/XPIAsD49nEojFzPKMKyeGhHpfQQOjwfQ5M0ZZoqYbVXCPi685IhsswNJbbdPg66ukMbbAbpEdRwAaCvwZdUa/XfRW3IXbtsA8y/cFrSl2KOFGXj5KRfyfsWOIXpXkHq7ekef8R8xNCFFEDYeXtKuhQnoLtel36o/Ptd94tNE0w1oMSH0CThpeeg4+4rrm7QSJwTMWf6VsCVQpAj9WTzrMXhNP+B 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, Oct 25, 2023 at 05:52:58PM +0900, Hyesoo Yu wrote: > If we only avoid using ALLOC_CMA for __GFP_TAGGED, would we still be able to use > the next iteration even if the hardware does not support "tag of tag" ? It depends on how the next iteration looks like. The plan was not to support this so that we avoid another complication where a non-tagged page is mprotect'ed to become tagged and it would need to be migrated out of the CMA range. Not sure how much code it would save. > I am not sure every vendor will support tag of tag, since there is no information > related to that feature, like in the Google spec document. If you are aware of any vendors not supporting this, please direct them to the Arm support team, it would be very useful information for us. Thanks. -- Catalin