Received: by 2002:ab2:1149:0:b0:1f3:1f8c:d0c6 with SMTP id z9csp2828410lqz; Wed, 3 Apr 2024 09:38:43 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCV2VPiO0BdvZoJqlZRXODbnmAnEYvZVR33eL/mNO8Sm9EEPpU+E9esuvyHQkAVSkk3G9a5zkIQZ0/HzqpHWUYnVH8DCQuRiqHOPa6aEmw== X-Google-Smtp-Source: AGHT+IEO52FvkOhwvmGGgSMlKp3vDUM0CZFJEOdCzu9itYUsxNjMjj0X+3KzZuFgyQ9cDasy9dGF X-Received: by 2002:a67:b104:0:b0:478:81f5:5b1f with SMTP id w4-20020a67b104000000b0047881f55b1fmr8390506vsl.27.1712162322989; Wed, 03 Apr 2024 09:38:42 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712162322; cv=pass; d=google.com; s=arc-20160816; b=kjs94wD0SXGO2OXfoNiffPOIO5LhZDwNV5sTLqQxTHThMISoU8Nu5lQGaiZm93w562 odOWsFok0PeNmPTZOBjf4Iw/DKa2iuTUHTpdPcr6NmYjxBEtviOUtRNBM4bQbCGt3cza XsCZI0QWsIObm2Kfh8yYy+sV18QiyEIC+ggZTom7DZT54BQhzWK8Z8ptycicvINJyrCF TNnlOmWAz36f6LBz7KGg46Mhl1lyYD7j7ggapsMbE4DNAsXOF85pCgsP1ELRhwhA5iOY KH9FmEy1tQ+GgdsVX0r+ckkLjuRp9gn/Q7SGDJMadmdB8m4wX4X4P+z9mU3kdfeFIUrw w3lA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=+bxf6nG0qtMk6HHP7EZn5m8gMgNToaSIgtcH7sjsAVg=; fh=3WR3VtZSzidzBlt5wFyFQCw6rBEIdlpHUUUowxl7bgM=; b=rHCIwvLcQ5rCCR8GH/DdYkrstqPTlnI7N0nNHi8fY9Tm14xk2K7vAyKeaf7YUfySG6 9sRIo4qwNRLOqcEc8KMeBtybnr+DR4NK34gndKmQaOMgYIG0QIuVTix9lilcbNVlB7+W YHq1LBJVWouKh5e6IwaywH89xH9SXrQZCGvYLl2OwPtHa3J+6EBD8k+sQiSRPyKsyqVR RqJvvFLpZ1uRQX8qONO7iaqxvL0Z4BufjAE5MWJRI+sn2obJ0ZH1/gZhnKansVPpZcdF F3KG5tBNBXlgvD32Esxz5tMBuwYL2vHD6TjFWw8p39MlbaiEWKXA7EHLsVP1Z61z7JL/ FPpQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-130205-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-130205-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id s14-20020a67e34e000000b004788403978esi865553vsm.341.2024.04.03.09.38.42 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Apr 2024 09:38:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-130205-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-130205-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-kernel+bounces-130205-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id A0CDB1C25DE4 for ; Wed, 3 Apr 2024 16:38:42 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B83B6150982; Wed, 3 Apr 2024 16:38:14 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3777150A60 for ; Wed, 3 Apr 2024 16:38:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712162294; cv=none; b=m2KvqmvmGubq5hmYhfXDm9AovcBVG/PHIUikPuvVTpJOOCNv0gBj4sHAPAmeLXfn1as2Sv752XdIqYX55Kqv81GCT8SLvBaJQa5/zgcTkUYhgDgYctGlPpu0pLIozBy60ipuUmaA6lM87EqBYSIEfjcAfohd/XjfBM69ReJ4YAI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712162294; c=relaxed/simple; bh=0uBvKsUXSPr3DSXxjUljvz/Au+xN1WNZFImPxCAyrsw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qzAk8ygXNJ/CmYonLCeWW8v1a/RaYS9VY1kHNPV80gk6UkWh3OWlADlPLLSycgYsf7nL8wVG8TR+h8tWkjL9krDe56X2UKw7QRc54b0RobTf6+e23DEtxrcuwFVuZ6JP9r0kk52PzqBnbCgaM81M6bBmqq04LBYDSVchIzFVmpI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=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 8B1321007; Wed, 3 Apr 2024 09:38:42 -0700 (PDT) Received: from [10.57.72.245] (unknown [10.57.72.245]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7F80F3F7B4; Wed, 3 Apr 2024 09:38:09 -0700 (PDT) Message-ID: <0793c3d9-589b-4550-a556-9a4fa5a6cec2@arm.com> Date: Wed, 3 Apr 2024 17:38:07 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 1/2] mm/madvise: introduce mkold_clean_ptes() batch helper Content-Language: en-GB To: Lance Yang , akpm@linux-foundation.org Cc: zokeefe@google.com, 21cnbao@gmail.com, shy828301@gmail.com, david@redhat.com, mhocko@suse.com, fengwei.yin@intel.com, xiehuan09@gmail.com, wangkefeng.wang@huawei.com, songmuchun@bytedance.com, peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240402124029.47846-1-ioworker0@gmail.com> <20240402124029.47846-2-ioworker0@gmail.com> From: Ryan Roberts In-Reply-To: <20240402124029.47846-2-ioworker0@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 02/04/2024 13:40, Lance Yang wrote: > Change the code that clears young and dirty bits from the PTEs to use > ptep_get_and_clear_full() and set_pte_at(), via the new mkold_clean_ptes() > batch helper function. > > Unfortunately, the per-pte get_and_clear/modify/set approach would result > in unfolding/refolding for contpte mappings on arm64. So we need to > override mkold_clean_ptes() for arm64 to avoid it. > > Suggested-by: David Hildenbrand > Suggested-by: Barry Song <21cnbao@gmail.com> > Suggested-by: Ryan Roberts > Signed-off-by: Lance Yang > --- > arch/arm64/include/asm/pgtable.h | 36 ++++++++++++++++++++++++++++++++ > arch/arm64/mm/contpte.c | 10 +++++++++ > include/linux/pgtable.h | 30 ++++++++++++++++++++++++++ > 3 files changed, 76 insertions(+) When I suggested splitting out this patch, this wasn't quite what I meant. Instead I intended for the first patch to make the MADV_FREE change and as part of that introduce mkold_clean_ptes() with a generic implementation. Then a second patch would do the arm64-specific specialization of mkold_clean_ptes() for an arm64-specific performance boost. In general it is often useful to separate core changes from arch changes where practical since they have different target audiences. > > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h > index 9fd8613b2db2..b032c107090c 100644 > --- a/arch/arm64/include/asm/pgtable.h > +++ b/arch/arm64/include/asm/pgtable.h > @@ -1086,6 +1086,27 @@ static inline bool pud_user_accessible_page(pud_t pud) > } > #endif > > +static inline void __mkold_clean_pte(struct vm_area_struct *vma, > + unsigned long addr, pte_t *ptep) > +{ > + pte_t old_pte, pte; > + > + pte = __ptep_get(ptep); > + do { > + old_pte = pte; > + pte = pte_mkclean(pte_mkold(pte)); > + pte_val(pte) = cmpxchg_relaxed(&pte_val(*ptep), > + pte_val(old_pte), pte_val(pte)); > + } while (pte_val(pte) != pte_val(old_pte)); > +} I'm not sure how value it is to split this out, given we are only exposing a batched version to the core. Perhaps just include the body in mkold_clean_ptes()? > + > +static inline void mkold_clean_ptes(struct vm_area_struct *vma, > + unsigned long addr, pte_t *ptep, unsigned int nr, int full) > +{ > + for (; nr-- > 0; ptep++, addr += PAGE_SIZE) > + __mkold_clean_pte(vma, addr, ptep); > +} > + > /* > * Atomic pte/pmd modifications. > */ > @@ -1379,6 +1400,8 @@ extern void contpte_wrprotect_ptes(struct mm_struct *mm, unsigned long addr, > extern int contpte_ptep_set_access_flags(struct vm_area_struct *vma, > unsigned long addr, pte_t *ptep, > pte_t entry, int dirty); > +extern void contpte_ptep_mkold_clean(struct vm_area_struct *vma, > + unsigned long addr, pte_t *ptep); Let's have this follow the same naming pattern; contpte_mkold_clean_ptes() > > static __always_inline void contpte_try_fold(struct mm_struct *mm, > unsigned long addr, pte_t *ptep, pte_t pte) > @@ -1603,6 +1626,18 @@ static inline int ptep_set_access_flags(struct vm_area_struct *vma, > return contpte_ptep_set_access_flags(vma, addr, ptep, entry, dirty); > } > > +#define mkold_clean_ptes mkold_clean_ptes > +static inline void mkold_clean_ptes(struct vm_area_struct *vma, > + unsigned long addr, pte_t *ptep, unsigned int nr, int full) > +{ > + pte_t orig_pte = __ptep_get(ptep); > + > + if (likely(!pte_valid_cont(orig_pte))) > + return __mkold_clean_ptes(vma, addr, ptep, nr, full); > + > + return contpte_ptep_mkold_clean(vma, addr, ptep);> +} This function is totally broken as far as I can tell. You are assuming if the first pte is not cont, then the whole range is not cont; you can't assume that. Then if you decide it is cont, you ignore nr and only fixup a single contpte block. Take a look at wrprotect_ptes() or another one of the batched helpers and follow that pattern. > + > #else /* CONFIG_ARM64_CONTPTE */ > > #define ptep_get __ptep_get > @@ -1622,6 +1657,7 @@ static inline int ptep_set_access_flags(struct vm_area_struct *vma, > #define wrprotect_ptes __wrprotect_ptes > #define __HAVE_ARCH_PTEP_SET_ACCESS_FLAGS > #define ptep_set_access_flags __ptep_set_access_flags > +#define mkold_clean_ptes __mkold_clean_ptes > > #endif /* CONFIG_ARM64_CONTPTE */ > > diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c > index 1b64b4c3f8bf..560622cfb2a9 100644 > --- a/arch/arm64/mm/contpte.c > +++ b/arch/arm64/mm/contpte.c > @@ -322,6 +322,16 @@ int contpte_ptep_test_and_clear_young(struct vm_area_struct *vma, > } > EXPORT_SYMBOL_GPL(contpte_ptep_test_and_clear_young); > > +void contpte_ptep_mkold_clean(struct vm_area_struct *vma, unsigned long addr, > + pte_t *ptep) > +{ > + ptep = contpte_align_down(ptep); > + addr = ALIGN_DOWN(addr, CONT_PTE_SIZE); > + > + __mkold_clean_ptes(vma, addr, ptep, CONT_PTES, 0); As above, this is broken as is. > +} > +EXPORT_SYMBOL_GPL(contpte_ptep_mkold_clean); > + > int contpte_ptep_clear_flush_young(struct vm_area_struct *vma, > unsigned long addr, pte_t *ptep) > { > diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h > index fa8f92f6e2d7..fd30779fe487 100644 > --- a/include/linux/pgtable.h > +++ b/include/linux/pgtable.h > @@ -391,6 +391,36 @@ static inline void mkold_ptes(struct vm_area_struct *vma, unsigned long addr, > } > #endif > > +#ifndef mkold_clean_ptes > +/** > + * mkold_clean_ptes - Mark PTEs that map consecutive pages of the same folio > + * as old and clean. > + * @vma: VMA the pages are mapped into. > + * @addr: Address the first page is mapped at. > + * @ptep: Page table pointer for the first entry. > + * @nr: Number of entries to mark old and clean. > + * > + * May be overridden by the architecture; otherwise, implemented as a simple > + * loop over ptep_get_and_clear_full(). How about "otherwise, implemented by get_and_clear/modify/set for each pte in the range."? > + * > + * Note that PTE bits in the PTE range besides the PFN can differ. For example, > + * some PTEs might be write-protected. > + * > + * Context: The caller holds the page table lock. The PTEs map consecutive > + * pages that belong to the same folio. The PTEs are all in the same PMD. > + */ > +static inline void mkold_clean_ptes(struct vm_area_struct *vma, > + unsigned long addr, pte_t *ptep, unsigned int nr, int full) You've included the "full" param in the function but not in the docs. I don't think the full param is valuable though; it doesn't make sense to call this function when tearing down a process. So drop the parameter and just call ptep_get_and_clear(). > +{ > + pte_t pte; > + > + for (; nr-- > 0; ptep++, addr += PAGE_SIZE) { nit: This is using a different pattern to all the other batch helpers (set_ptes(), wrprotect_ptes() clear_full_ptes()). > + pte = ptep_get_and_clear_full(vma->vm_mm, addr, ptep, full); > + set_pte_at(vma->vm_mm, addr, ptep, pte_mkclean(pte_mkold(pte))); > + } > +} > +#endif > + > #ifndef __HAVE_ARCH_PMDP_TEST_AND_CLEAR_YOUNG > #if defined(CONFIG_TRANSPARENT_HUGEPAGE) || defined(CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG) > static inline int pmdp_test_and_clear_young(struct vm_area_struct *vma,