Re: [PATCH 2/3] loongarch/mm: Drop all pxdp_get()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm: performance regression from de-inlining pte_clear()
--

commit 5d80651056844549679369970919b58e26bc34bf
Author: Anshuman Khandual <anshuman.khandual@arm.com>

loongarch/mm: Drop all pxdp_get()

This patch removes redundant loongarch-specific pxdp_get() helpers, relying
on the generic ones from include/linux/pgtable.h. To prevent build failures,
it moves some dependent functions to out-of-line implementations.

> diff --git a/arch/loongarch/include/asm/pgtable.h b/arch/loongarch/include/asm/pgtable.h
> index a05f6a4928dc6..b1060b86d5353 100644
> --- a/arch/loongarch/include/asm/pgtable.h
> +++ b/arch/loongarch/include/asm/pgtable.h

[ ... ]

> @@ -378,12 +375,7 @@ static inline void set_pte(pte_t *ptep, pte_t pteval)
>  #endif
>  }
>  
> -static inline void pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep)
> -{
> -	pte_t pte = ptep_get(ptep);
> -	pte_val(pte) &= _PAGE_GLOBAL;
> -	set_pte(ptep, pte);
> -}
> +void pte_clear(struct mm_struct *mm, unsigned long addr, pte_t *ptep);

[Severity: High]
Does removing 'static inline' and moving pte_clear() out-of-line introduce a
performance regression?

pte_clear() is a core memory management primitive executed iteratively in
extremely hot paths. For instance, zap_pte_range() processes up to 512 PTEs
per PMD during munmap or madvise. Replacing inline bitwise operations with
function calls during large VMA teardown introduces a significant overhead
for any unprivileged process allocating and freeing memory.

Could this be avoided by expanding ptep_get(ptep) to its equivalent
READ_ONCE(*ptep) inside the inline definition instead of moving the function
out-of-line?

[ ... ]

> @@ -618,16 +610,8 @@ static inline pmd_t pmd_mkinvalid(pmd_t pmd)
>   * different prototype.
>   */
>  #define __HAVE_ARCH_PMDP_HUGE_GET_AND_CLEAR
> -static inline pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm,
> -					    unsigned long address, pmd_t *pmdp)
> -{
> -	pmd_t old = pmdp_get(pmdp);
> -
> -	pmd_clear(pmdp);
> -
> -	return old;
> -}
>  
> +pmd_t pmdp_huge_get_and_clear(struct mm_struct *mm, unsigned long address, pmd_t *pmdp);

[Severity: High]
Does moving pmdp_huge_get_and_clear() out-of-line similarly negatively impact
THP teardown performance?

Like pte_clear(), this function operates on hot paths, and substituting an
inline definition with a function call introduces overhead. Could this also
be kept inline by expanding pmdp_get(pmdp) to READ_ONCE(*pmdp)?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923043226.331880-1-anshuman.khandual@arm.com?part=2