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 34CE8C4345F for ; Fri, 3 May 2024 10:02:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE1446B009F; Fri, 3 May 2024 06:02:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B69546B00A1; Fri, 3 May 2024 06:02:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A58626B00A2; Fri, 3 May 2024 06:02:15 -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 838886B009F for ; Fri, 3 May 2024 06:02:15 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2FF7912109D for ; Fri, 3 May 2024 10:02:15 +0000 (UTC) X-FDA: 82076644230.30.E95DAD6 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf11.hostedemail.com (Postfix) with ESMTP id 5DC8840006 for ; Fri, 3 May 2024 10:02:12 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf11.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1714730532; 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=taqLiHW8NwH3ME3k7brdYG0U1D77AhEV+qHx95Ni7oo=; b=Qgt8KO90PHugEDc0GnjMJbcZgutuj1zkMhUx/h1bt+rKmqziqM1oXoQIs3PQRkL89CVZ4H 6tXEuXdiDbGFmr5LV/2h3JSIcorOnMD/ibYUWNFOfwSefgOfpmcGjoXqGs7Ib8Fhu4wVtf wS1DZ/jcaXiRvR5P0QFBhMlD6XjqRZo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1714730532; a=rsa-sha256; cv=none; b=ad44A1b3DSBmVyBG8m4C8UbX3keLUpz2+ql8bmXXp7SMcD0ha9FId8eapDCP49EDN6qIzd fwV/ofYbBmMTcqiJqUM/yEzmBvMmMn4/WAcQCxlKth7Gk9QxO9htbV0m8ZZuURRLksAiSC ObaO2qmOAet2fbtqTS31cwi0ErEe/rE= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf11.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@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 C0D3D2F4; Fri, 3 May 2024 03:02:36 -0700 (PDT) Received: from [10.57.67.51] (unknown [10.57.67.51]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8B99C3F793; Fri, 3 May 2024 03:02:08 -0700 (PDT) Message-ID: Date: Fri, 3 May 2024 11:02:06 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/6] mm: introduce arch_do_swap_page_nr() which allows restore metadata for nr pages Content-Language: en-GB To: Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, linux-mm@kvack.org Cc: baolin.wang@linux.alibaba.com, chrisl@kernel.org, david@redhat.com, hanchuanhua@oppo.com, hannes@cmpxchg.org, hughd@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, surenb@google.com, v-songbaohua@oppo.com, willy@infradead.org, xiang@kernel.org, ying.huang@intel.com, yosryahmed@google.com, yuzhao@google.com, ziy@nvidia.com, Khalid Aziz , "David S. Miller" , Andreas Larsson References: <20240503005023.174597-1-21cnbao@gmail.com> <20240503005023.174597-5-21cnbao@gmail.com> From: Ryan Roberts In-Reply-To: <20240503005023.174597-5-21cnbao@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 5DC8840006 X-Stat-Signature: 1y7xkhoojkigcgxfjjtikf1xtgqpi3gp X-Rspam-User: X-HE-Tag: 1714730532-105713 X-HE-Meta: U2FsdGVkX1+56wmTbqgxCKocPByT0M6uovJyKbGb6Y7ADivx1UfyQ76Q9ax5t4OoLNx20PTEbF0+IEbLo1ssvCblqkG3qujg16enpLS/TbbB65Nia7BEoL8ssUqKm9J2dQ48fbWs3JrcglRQFZG3dajQg3r4DC8oRlYEc7WRS5tL+Dh+e3kYc39hGfXhwYQyu0l198pWQiiamU5zlcwQ9849MyWMiv3xzZOQCzhIxh7ShOu1c9qHNbpyWj/noecEkMb81uMcHoYq8kSWhjgHr/G1J+Hl9nZcQSQ5uN4wl20E1N8GDWhacoB4URbbiuZal5fXwWzmgLUWFJVcxsnbaK5TpViKSIjFC1crAl2neNpmIfJqhv5hB5k/Kc2BW8oPmti5wyBD0ft0C8krzlhMZAMd8gJ+g5FJ865a50byn8kPLgSO1SKUXZYxq1I47HggBXArWGaL6PJV4vPigHJ6bpjIy3FXAF6WsYSfrkWP4Jh8MPDzNdGfhl/P8VZgO6JiyHRl6Pq1TU5mldq0fehe95YtNMyLJg3QwktWb7fa8guGMlpTD3seOMrz/nqXi57Rbx2epW5aHHV7leR1z5MlA9jCQ5CkFPinlXTHvYzKCqXp7I6PekuTwMGKXYUjjmOoie0uQqFjhndDIxNECXFq9JKHYO//fbuG0txgX4sMsIQAzQVatLOCVxsJMEqIYeTINvpNIjZWGDjqpwHpYSejtjaWPKGsvWEOZFilD+3phlJtNbRKqkLLmEdPTioc5CJKyMEAkdw3inPmGy0z2Ecq0fxQL0lV4lnTrdGweLTHCn4y8byTdehdAs/yd9EL1lNGp3tYMpFlG8YOXZUdv2GMvBl2gXmrwtSKO9mV/vHbWtghRp1CoLtofqEF6P78w8us/7xP3IuLnrNSOsJPeypp3Qo3iiwBMlorsn/ZwMjKGGXOo7JaHHBPf6tScZz/7fpk6R+/9NrWPDWn2fnPj0e z/Gmxb7b SIze+VtPsT0OeCVRk0/UIGdgGE88Sl9CtmqXAtr7bhF89P7LGSkq3tDAAu6toOYG4zkdOKytK1g9Nm2lErY4H4TPD0+APv3NSoFb0xTM0JQSopwHXuLTSO4pvh3cal1XJ9b/ptjlU1RAAUT3GqC2D7TVDIbGZ+RbmSwJ/4Gpepv43xnFSbZudV2f5qCCyL3GNLnhhcHpwX4OcLdRoofgBF4fsnrc/hk+ML9TPVA3iWFkMFKH6zdglBa1ZJdxcymRC8Y6x7x4JVIKUTXOFlYa3M3yBm5L/+BpxjuhFTpeyGouR8sR1R+ioYu+Lp5cocNyvUyikYgoqI/0s8o+xbC1EQWx9CJeYabYB37oK9V3DU2hGaQRTE2MVcwFXaSEPOocCGtwClModAhTKdmibMZBNEg9vW06hwwwp6m1y22avv+8XG/3iSGB29EShkm4jGcZypJI6B4ONV79uw/E= 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 03/05/2024 01:50, Barry Song wrote: > From: Barry Song > > Should do_swap_page() have the capability to directly map a large folio, > metadata restoration becomes necessary for a specified number of pages > denoted as nr. It's important to highlight that metadata restoration is > solely required by the SPARC platform, which, however, does not enable > THP_SWAP. Consequently, in the present kernel configuration, there > exists no practical scenario where users necessitate the restoration of > nr metadata. Platforms implementing THP_SWAP might invoke this function > with nr values exceeding 1, subsequent to do_swap_page() successfully > mapping an entire large folio. Nonetheless, their arch_do_swap_page_nr() > functions remain empty. > > Cc: Khalid Aziz > Cc: "David S. Miller" > Cc: Andreas Larsson > Signed-off-by: Barry Song > --- > include/linux/pgtable.h | 26 ++++++++++++++++++++------ > mm/memory.c | 3 ++- > 2 files changed, 22 insertions(+), 7 deletions(-) > > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > index 18019f037bae..463e84c3de26 100644 > --- a/include/linux/pgtable.h > +++ b/include/linux/pgtable.h > @@ -1084,6 +1084,15 @@ static inline int pgd_same(pgd_t pgd_a, pgd_t pgd_b) > }) > > #ifndef __HAVE_ARCH_DO_SWAP_PAGE > +static inline void arch_do_swap_page_nr(struct mm_struct *mm, > + struct vm_area_struct *vma, > + unsigned long addr, > + pte_t pte, pte_t oldpte, > + int nr) > +{ > + > +} > +#else > /* > * Some architectures support metadata associated with a page. When a > * page is being swapped out, this metadata must be saved so it can be > @@ -1092,12 +1101,17 @@ static inline int pgd_same(pgd_t pgd_a, pgd_t pgd_b) > * page as metadata for the page. arch_do_swap_page() can restore this > * metadata when a page is swapped back in. > */ > -static inline void arch_do_swap_page(struct mm_struct *mm, > - struct vm_area_struct *vma, > - unsigned long addr, > - pte_t pte, pte_t oldpte) This hook seems to be very similar to arch_swap_restore(), I wonder if it makes sense to merge them. Out of scope for this patch series though. > -{ > - > +static inline void arch_do_swap_page_nr(struct mm_struct *mm, > + struct vm_area_struct *vma, > + unsigned long addr, > + pte_t pte, pte_t oldpte, > + int nr) > +{ > + for (int i = 0; i < nr; i++) { > + arch_do_swap_page(vma->vm_mm, vma, addr + i * PAGE_SIZE, > + pte_advance_pfn(pte, i), > + pte_advance_pfn(oldpte, i)); It seems a bit odd to create a batched version of this, but not allow arches to take advantage. Although I guess your point is that only SPARC implements it and on that platform nr will always be 1? So no point right now? So this is just a convenience for do_swap_page()? Makes sense. Reviewed-by: Ryan Roberts > + } > } > #endif > > diff --git a/mm/memory.c b/mm/memory.c > index f033eb3528ba..74cdefd58f5f 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -4266,7 +4266,8 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > VM_BUG_ON(!folio_test_anon(folio) || > (pte_write(pte) && !PageAnonExclusive(page))); > set_pte_at(vma->vm_mm, vmf->address, vmf->pte, pte); > - arch_do_swap_page(vma->vm_mm, vma, vmf->address, pte, vmf->orig_pte); > + arch_do_swap_page_nr(vma->vm_mm, vma, vmf->address, > + pte, vmf->orig_pte, 1); > > folio_unlock(folio); > if (folio != swapcache && swapcache) {