From: Ryan Roberts <ryan.roberts@arm.com>
To: Lance Yang <ioworker0@gmail.com>, akpm@linux-foundation.org
Cc: david@redhat.com, 21cnbao@gmail.com, mhocko@suse.com,
fengwei.yin@intel.com, zokeefe@google.com, shy828301@gmail.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
Subject: Re: [PATCH v5 2/2] mm/arm64: override mkold_clean_ptes() batch helper
Date: Thu, 11 Apr 2024 14:17:48 +0100 [thread overview]
Message-ID: <3cd1036d-3814-4a10-b6d2-099937ceabc8@arm.com> (raw)
In-Reply-To: <20240408042437.10951-3-ioworker0@gmail.com>
On 08/04/2024 05:24, Lance Yang wrote:
> 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.
IIRC, in the last version, I suggested copying the wrprotect_ptes() pattern to
correctly iterate over contpte blocks. I meant for you to take it as inspiration
but looks like you have done a carbon copy, including lots of things that are
unneeded here. That's my fault for not being clear - sorry!
>
> Suggested-by: David Hildenbrand <david@redhat.com>
> Suggested-by: Barry Song <21cnbao@gmail.com>
> Suggested-by: Ryan Roberts <ryan.roberts@arm.com>
> Signed-off-by: Lance Yang <ioworker0@gmail.com>
> ---
> arch/arm64/include/asm/pgtable.h | 55 ++++++++++++++++++++++++++++++++
> arch/arm64/mm/contpte.c | 15 +++++++++
> 2 files changed, 70 insertions(+)
>
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 9fd8613b2db2..395754638a9a 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -1223,6 +1223,34 @@ static inline void __wrprotect_ptes(struct mm_struct *mm, unsigned long address,
> __ptep_set_wrprotect(mm, address, ptep);
> }
>
> +static inline void ___ptep_mkold_clean(struct mm_struct *mm, unsigned long addr,
> + pte_t *ptep, pte_t pte)
> +{
> + pte_t old_pte;
> +
> + 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));
> +}
Given you are clearing old and dirty, you have nothing to race against, so you
shouldn't need the cmpxchg loop here; just a get/modify/set should do? Of course
if you are setting one or the other, then you need the loop.
> +
> +static inline void __ptep_mkold_clean(struct mm_struct *mm, unsigned long addr,
> + pte_t *ptep)
> +{
> + ___ptep_mkold_clean(mm, addr, ptep, __ptep_get(ptep));
> +}
I don't see a need for this intermediate function.
> +
> +static inline void __mkold_clean_ptes(struct mm_struct *mm, unsigned long addr,
> + pte_t *ptep, unsigned int nr)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < nr; i++, addr += PAGE_SIZE, ptep++)
It would probably be good to use the for() loop pattern used by the generic
impls here too.
> + __ptep_mkold_clean(mm, addr, ptep);
> +}
> +
> #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> #define __HAVE_ARCH_PMDP_SET_WRPROTECT
> static inline void pmdp_set_wrprotect(struct mm_struct *mm,
> @@ -1379,6 +1407,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_mkold_clean_ptes(struct mm_struct *mm, unsigned long addr,
> + pte_t *ptep, unsigned int nr);
>
> static __always_inline void contpte_try_fold(struct mm_struct *mm,
> unsigned long addr, pte_t *ptep, pte_t pte)
> @@ -1603,6 +1633,30 @@ 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 mm_struct *mm, unsigned long addr,
> + pte_t *ptep, unsigned int nr)
> +{
> + if (likely(nr == 1)) {
> + /*
> + * Optimization: mkold_clean_ptes() can only be called for present
> + * ptes so we only need to check contig bit as condition for unfold,
> + * and we can remove the contig bit from the pte we read to avoid
> + * re-reading. This speeds up madvise(MADV_FREE) which is sensitive
> + * for order-0 folios. Equivalent to contpte_try_unfold().
> + */
Is this true? Do you have data that shows the cost? If not, I'd prefer to avoid
the optimization and do it the more standard way:
contpte_try_unfold(mm, addr, ptep, __ptep_get(ptep));
> + pte_t orig_pte = __ptep_get(ptep);
> +
> + if (unlikely(pte_cont(orig_pte))) {
> + __contpte_try_unfold(mm, addr, ptep, orig_pte);
> + orig_pte = pte_mknoncont(orig_pte);
> + }
> + ___ptep_mkold_clean(mm, addr, ptep, orig_pte);
> + } else {
> + contpte_mkold_clean_ptes(mm, addr, ptep, nr);
> + }
...but I don't think you should ever need to unfold in the first place. Even if
it's folded and you are trying to clear access/dirty for a single pte, you can
just clear the whole block. See existing comment in
contpte_ptep_test_and_clear_young().
So this ends up as something like:
static inline void clear_young_dirty_ptes(struct mm_struct *mm,
unsigned long addr, pte_t *ptep, unsigned int nr,
bool clear_young, bool clear_dirty)
{
if (likely(nr == 1 && !pte_cont(__ptep_get(ptep))))
clear_young_dirty_ptes(mm, addr, ptep, nr,
clear_young, clear_dirty);
else
contpte_clear_young_dirty_ptes(mm, addr, ptep, nr,
clear_young, clear_dirty);
}
> +}
> +
> #else /* CONFIG_ARM64_CONTPTE */
>
> #define ptep_get __ptep_get
> @@ -1622,6 +1676,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..dbff9c5e9eff 100644
> --- a/arch/arm64/mm/contpte.c
> +++ b/arch/arm64/mm/contpte.c
> @@ -361,6 +361,21 @@ void contpte_wrprotect_ptes(struct mm_struct *mm, unsigned long addr,
> }
> EXPORT_SYMBOL_GPL(contpte_wrprotect_ptes);
>
> +void contpte_mkold_clean_ptes(struct mm_struct *mm, unsigned long addr,
> + pte_t *ptep, unsigned int nr)
> +{
> + /*
> + * If clearing the young and dirty bits for an entire contig range, we can
> + * avoid unfolding. Just set old/clean and wait for the later mmu_gather
> + * flush to invalidate the tlb. If it's a partial range though, we need to
> + * unfold.
> + */
nit: Please reflow comments like this to 80 cols.
We can avoid unfolding in all cases. See existing comment in
contpte_ptep_test_and_clear_young(). Suggest something like this (untested):
void clear_young_dirty_ptes(struct mm_struct *mm, unsigned long addr,
pte_t *ptep, unsigned int nr,
bool clear_young, bool clear_dirty)
{
/*
* We can safely clear access/dirty without needing to unfold from the
* architectures perspective, even when contpte is set. If the range
* starts or ends midway through a contpte block, we can just expand to
* include the full contpte block. While this is not exactly what the
* core-mm asked for, it tracks access/dirty per folio, not per page.
* And since we only create a contpte block when it is covered by a
* single folio, we can get away with clearing access/dirty for the
* whole block.
*/
unsigned int start = addr;
unsigned int end = start + nr;
if (pte_cont(__ptep_get(ptep + nr - 1)))
end = ALIGN(end, CONT_PTE_SIZE);
if (pte_cont(__ptep_get(ptep))) {
start = ALIGN_DOWN(start, CONT_PTE_SIZE);
ptep = contpte_align_down(ptep);
}
__clear_young_dirty_ptes(mm, start, ptep, end - start,
clear_young, clear_dirty);
}
Thanks,
Ryan
> +
> + contpte_try_unfold_partial(mm, addr, ptep, nr);
> + __mkold_clean_ptes(mm, addr, ptep, nr);
> +}
> +EXPORT_SYMBOL_GPL(contpte_mkold_clean_ptes);
> +
> int contpte_ptep_set_access_flags(struct vm_area_struct *vma,
> unsigned long addr, pte_t *ptep,
> pte_t entry, int dirty)
next prev parent reply other threads:[~2024-04-11 13:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-08 4:24 [PATCH v5 0/2] mm/madvise: enhance lazyfreeing with mTHP in madvise_free Lance Yang
2024-04-08 4:24 ` [PATCH v5 1/2] mm/madvise: optimize " Lance Yang
2024-04-11 11:11 ` Ryan Roberts
2024-04-11 11:20 ` David Hildenbrand
2024-04-11 11:27 ` Ryan Roberts
2024-04-11 12:23 ` Lance Yang
2024-04-11 13:51 ` Ryan Roberts
2024-04-11 13:55 ` David Hildenbrand
2024-04-11 12:46 ` Lance Yang
2024-04-11 13:48 ` Ryan Roberts
2024-04-11 14:07 ` Lance Yang
2024-04-11 14:39 ` Ryan Roberts
2024-04-11 14:42 ` David Hildenbrand
2024-04-12 1:48 ` Lance Yang
2024-04-08 4:24 ` [PATCH v5 2/2] mm/arm64: override mkold_clean_ptes() batch helper Lance Yang
2024-04-11 13:17 ` Ryan Roberts [this message]
2024-04-12 2:09 ` Lance Yang
2024-04-12 11:21 ` Ryan Roberts
2024-04-10 21:50 ` [PATCH v5 0/2] mm/madvise: enhance lazyfreeing with mTHP in madvise_free Andrew Morton
2024-04-11 5:01 ` Lance Yang
2024-04-11 10:29 ` Ryan Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3cd1036d-3814-4a10-b6d2-099937ceabc8@arm.com \
--to=ryan.roberts@arm.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=fengwei.yin@intel.com \
--cc=ioworker0@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=minchan@kernel.org \
--cc=peterx@redhat.com \
--cc=shy828301@gmail.com \
--cc=songmuchun@bytedance.com \
--cc=wangkefeng.wang@huawei.com \
--cc=xiehuan09@gmail.com \
--cc=zokeefe@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox