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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 1C4D3C4167B for ; Fri, 8 Dec 2023 13:22:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=NT6b5qwbMhWUI82tDJ7GR/wYz+NHzbKeKV7YGCwqD6w=; b=LSP4cWrDU4BYcX X6O0vfYg2CH1l0bPHcEFNTWjtjdh2pTbLAaO4a2pn+gAMf1CrxDlIqMVfz0AFTmjaBsj9FyAB8tt4 EwY74vvHsGUf2SlKhJPssZeV/bIikiigpYvXAfHChklyTVtqTEmKrzt6iJTQdXUmmN/Gpo4JrfVRX 0C1zxmMlrsoZi5SeP/ZUXBXZMJKnOmt+4ZjsGHorZcAh1/Adc+B1JcyaBeKZkKVbIkrJIafz0dCEZ z3BI/HXqTkgbZAd2pIkoXVpjqN7T5evWLdHsMv+3eB0kI0EveEckphlLd7F+MkxdLW4ebaexKRngm +bhWOTawKAno/UymJySQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rBao0-00FgDc-0v; Fri, 08 Dec 2023 13:22:12 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rBany-00FgDR-2L for linux-arm-kernel@bombadil.infradead.org; Fri, 08 Dec 2023 13:22:10 +0000 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-Disposition: inline In-Reply-To: <20231208073401.70153-1-v-songbaohua@oppo.com> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel