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 94748C4167B for ; Fri, 8 Dec 2023 13:22:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 172CF6B007B; Fri, 8 Dec 2023 08:22:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 122666B007E; Fri, 8 Dec 2023 08:22:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 010AB6B0080; Fri, 8 Dec 2023 08:22:16 -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 E35F76B007B for ; Fri, 8 Dec 2023 08:22:16 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 92713160145 for ; Fri, 8 Dec 2023 13:22:16 +0000 (UTC) X-FDA: 81543714672.15.0090A66 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 2895812000A for ; Fri, 8 Dec 2023 13:22:13 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=qA1xTFy2; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702041735; a=rsa-sha256; cv=none; b=dQP644kqygbvRF94OWh1up/Oc+S34P4PR0ssmu6YVTLyMrcqZ0zym87E/6N+ylvnFZRZdf jiDho0FGvwIYsta7RDYy99xPanwlw/nd4UaL6b9U+Pl3RIzvWITwHig7s2kVFxi+KLIwsb PJ4Tuy6EIPw6YiaSdDh5BApNyAitLOE= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=qA1xTFy2; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702041735; 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=iy/BnsFgH54qc/gUsqH+n1Dt1dH36pA1igQK0/A27e8=; b=ORj7ptr3eB/vMm0IowgtS3A50dupVkGVR/LMHLVnkWxTeaZe62QFtC+B9CeBZ6PtitD2YS AEFb6Xsd8GBklBtK8ENacGVWomZ8X1CF+raSmql89KXvvL6cr9pHNqyxK6wOJEO6I7dTUh gXisx6HbRegKx+tSrPEU5FX6yO4n/yI= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=iy/BnsFgH54qc/gUsqH+n1Dt1dH36pA1igQK0/A27e8=; b=qA1xTFy26X4kaYS1n6Ovfc01qh q6DuZLG6IQFgGDNzwWDXUE9cjwdKZkSYQWJtQPCjh213FN9hLqimR4PyUmtLc491ao2vlb6faOtoF baKCzIRElSptkWh9ye14i0U6MbY5uFtjNCPZfFdOT0fYyWZjkgN5g+CC6kqT5MNM77XKXO4YwAlsf Pt+MUziyy3rFcFRaJ/utVGIV5ujplXsYAPj+Y1C178Zfsq48btQmDxkwta9EbGk18N8gVQKYs+JNW EiGJGuA1vRg6d0xvhaHOspfIunCCQ7XrJIwjWugm/QwHFsmgIju9XpJtzYQYgzPGsU7F0EwjD/mmV YiTYV1Ow==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rBanr-005oGS-Hm; Fri, 08 Dec 2023 13:22:03 +0000 Date: Fri, 8 Dec 2023 13:22:03 +0000 From: Matthew Wilcox To: Barry Song <21cnbao@gmail.com> Cc: akpm@linux-foundation.org, catalin.marinas@arm.com, david@redhat.com, linux-mm@kvack.org, ryan.roberts@arm.com, steven.price@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, mhocko@suse.com, shy828301@gmail.com, v-songbaohua@oppo.com, wangkefeng.wang@huawei.com, xiang@kernel.org, ying.huang@intel.com, yuzhao@google.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: mm: support THP_SWAP on hardware with MTE Message-ID: References: <20231208073401.70153-1-v-songbaohua@oppo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231208073401.70153-1-v-songbaohua@oppo.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 2895812000A X-Stat-Signature: phzir9mwjakwbsujczew91ysdqof96yn X-Rspam-User: X-HE-Tag: 1702041733-299792 X-HE-Meta: U2FsdGVkX18ndk3Sw7GRhesEpkdmzCMFkegIeZCPkuZcZiQRZS7fu3lnoSkhLGZy7H6ccZs40f5KIEqxsw9iLuhOoFMC3jE1TY06kMKrzE2Ma1MzJRh2jz13BkUi4ZijSUSU3tJOqpGmz8fRRWr8HiLeXg0Cd7O8LnsIqVRNjnFs34xYDtGBi1J2391cbrKsJnOivzz3mTi3gP8Fn8RN/fINkiq639elXhQLBE+fGkcKwNrxlB5t+MHsDZmP9VSZoCuV64JgLHDsZnCjyqOBCrxvzkfZWJDe5cTjFGCtjomEyo58ft+b+Yq1Au5sHli2Pmusy+O8IEsidGpjDrQqxqlydfCpIfo1mF7NPLzTyN3YUSOxbUn+NpdIViNBPcTf2O0khXxTeRqBczZyQ76+7YTbnhubLQO9JCe5zsWMdasmECRsJfHZgMXfOEUOcvS6j4MzgoVLpi+bO6mDZgzjjl2UmPidDHB9GY7kqywBPQ2HZ3NfphsnpZDR3OhpgaBA/Vyg5I7bWunm8cc16H/THHmtgDrgTBprSFvGyH34yBHXOafgcxjGJsddmr6/XH8xISwywBbC+HxneYNh71yONA3OGUcI2FubWqEiGUReFDK8tXmPrDy0gm6fM6UTPZsHDbuhPP2Gi7nptMQtdV+CneTV8Aj5e4mfPrp1GBxk/p4RLV8n4cYniktENVkdRmkr0oTtUKdOdyVsSt7712q00H2nD0aj19B9QAXraySgpZGqE8+oEAS7XRlCZzTesvPc45PJeslrhAfsZB6/D67Fp2toJogg8sSu1C/W1AaP3tTBqpgjXAy/mKCHCmTRUIG+pR6JsZcInfGd7geLfP3xfTjCuGHjfkMp/HM9UVg5EBoagni9cpR3oW069B/MCalO4w0eMiFKaAS+rxIl14I8HIS+vXB5fpQsz7cyeFgCkJ5sGELr/WfZwn+aWlqnpXo/RhqKzbCAH1nEuvsf8vE y0VGGSBj CZv2JV7pRcVtmuyCjn7gC5vU/DDIBLH5bp+RcPmAhQtOmgtr2zUbSmaXyVi9U2pabyLnJEJ+dID4HOe/diSY3kJ+eGfxd0fxNAwlSHiXJNByquNe8hCk6drFRZPSoMftLex5+pTNp84Y+HoYi1uF/7vwXmYy79Jk9D75PmA1xl0tKmAm+JjVyHJNDbA== 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 Fri, Dec 08, 2023 at 08:34:01PM +1300, Barry Song wrote: > arch_prepare_to_swap() should take folio rather than page as parameter > because we support THP swap-out as a whole. It saves tags for all > pages in a large folio. > > Meanwhile, arch_swap_restore() now moves to use page parameter rather > than folio because swap-in, refault and MTE tags are working at the > granularity of base pages rather than folio: > 1. a large folio in swapcache can be partially unmapped, thus, MTE > tags for the unmapped pages will be invalidated; > 2. users might use mprotect() to set MTEs on a part of a large folio. I would argue that using mprotect() to set MTEs on part of a large folio should cause that folio to be split. Could the user give us any stronger signal that this memory is being used for different purposes, and therefore should not be managed as a single entity? > Thus, it won't be easy to manage MTE tags at the granularity of folios > since we do have some cases in which a part of pages in a large folios > have valid tags, while the other part of pages haven't. Furthermore, > trying to restore MTE tags for a whole folio can lead to many loops and > early exiting even if the large folio in swapcache are still entirely > mapped since do_swap_page() only sets PTE and frees swap for the base > page where PF is happening. > > But we still have a chance to restore tags for a whole large folio > once we support swap-in large folio. So this job is deferred till we > can do refault and swap-in as a large folio. I strongly disagree with changing the interface to arch_swap_restore() from folio to page.