From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: "Lorenzo Stoakes (Oracle)" <ljs@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>, Zi Yan <ziy@nvidia.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Nico Pache <npache@redhat.com>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 8/9] mm/huge_memory: deduplicate zap_huge_pmd() further by tracking state
Date: Fri, 20 Mar 2026 11:49:18 +0800 [thread overview]
Message-ID: <d67ff262-a627-4cd3-b126-dd82eb8d3412@linux.alibaba.com> (raw)
In-Reply-To: <440f68edcb597c28918d89b0be279d498561c89a.1773924928.git.ljs@kernel.org>
On 3/19/26 9:00 PM, Lorenzo Stoakes (Oracle) wrote:
> The flush_needed boolean is really tracking whether a PMD entry is present,
> so use it that way directly and rename it to is_present.
>
> Deduplicate the folio_remove_rmap_pmd() and folio map count warning between
> present and device private by tracking where we need to remove the rmap.
>
> We can also remove the comment about using flush_needed to track whether a
> PMD entry is present as it's now irrelevant.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
> ---
> mm/huge_memory.c | 28 +++++++++++++---------------
> 1 file changed, 13 insertions(+), 15 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index c4e00c645e58..22715027e56c 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2430,9 +2430,10 @@ static inline void zap_deposited_table(struct mm_struct *mm, pmd_t *pmd)
> bool zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> pmd_t *pmd, unsigned long addr)
> {
> + bool needs_remove_rmap = false;
> struct folio *folio = NULL;
> bool needs_deposit = false;
> - bool flush_needed = false;
> + bool is_present = false;
> spinlock_t *ptl;
> pmd_t orig_pmd;
>
> @@ -2449,6 +2450,7 @@ bool zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> */
> orig_pmd = pmdp_huge_get_and_clear_full(vma, addr, pmd,
> tlb->fullmm);
> +
> arch_check_zapped_pmd(vma, orig_pmd);
> tlb_remove_pmd_tlb_entry(tlb, pmd, addr);
> if (vma_is_special_huge(vma))
> @@ -2458,17 +2460,15 @@ bool zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> goto out;
> }
>
> - if (pmd_present(orig_pmd)) {
> + is_present = pmd_present(orig_pmd);
> + if (is_present) {
> folio = pmd_folio(orig_pmd);
> -
> - flush_needed = true;
> - folio_remove_rmap_pmd(folio, &folio->page, vma);
> - WARN_ON_ONCE(folio_mapcount(folio) < 0);
> + needs_remove_rmap = true;
> } else if (pmd_is_valid_softleaf(orig_pmd)) {
> const softleaf_t entry = softleaf_from_pmd(orig_pmd);
>
> folio = softleaf_to_folio(entry);
> -
> + needs_remove_rmap = folio_is_device_private(folio);
> if (!thp_migration_supported())
> WARN_ONCE(1, "Non present huge pmd without pmd migration enabled!");
> } else {
> @@ -2483,27 +2483,25 @@ bool zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> add_mm_counter(tlb->mm, mm_counter_file(folio),
> -HPAGE_PMD_NR);
>
> - /*
> - * Use flush_needed to indicate whether the PMD entry
> - * is present, instead of checking pmd_present() again.
> - */
> - if (flush_needed && pmd_young(orig_pmd) &&
> + if (is_present && pmd_young(orig_pmd) &&
> likely(vma_has_recency(vma)))
> folio_mark_accessed(folio);
> }
>
> - if (folio_is_device_private(folio)) {
> + if (needs_remove_rmap) {
> folio_remove_rmap_pmd(folio, &folio->page, vma);
> WARN_ON_ONCE(folio_mapcount(folio) < 0);
> - folio_put(folio);
> }
>
> out:
> if (arch_needs_pgtable_deposit() || needs_deposit)
> zap_deposited_table(tlb->mm, pmd);
>
> + if (needs_remove_rmap && !is_present)
> + folio_put(folio);
> +
This kind of deduplication splits the device folio handling into three
places, which is not easy to understand (at least for me), since the
device folio has some special handling.
Especially here, without looking closely at the if condition, it is
unclear why we need to call folio_put(). Maybe some comments?
Anyway, I don't have a strong opinion. Let's wait for others' preferences.
next prev parent reply other threads:[~2026-03-20 3:49 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 13:00 [PATCH v2 0/9] mm/huge_memory: refactor zap_huge_pmd() Lorenzo Stoakes (Oracle)
2026-03-19 13:00 ` [PATCH v2 1/9] mm/huge_memory: simplify vma_is_specal_huge() Lorenzo Stoakes (Oracle)
2026-03-19 16:52 ` Kiryl Shutsemau
2026-03-19 17:16 ` Lorenzo Stoakes (Oracle)
2026-03-19 13:00 ` [PATCH v2 2/9] mm/huge: avoid big else branch in zap_huge_pmd() Lorenzo Stoakes (Oracle)
2026-03-19 13:00 ` [PATCH v2 3/9] mm/huge_memory: have zap_huge_pmd return a boolean, add kdoc Lorenzo Stoakes (Oracle)
2026-03-19 13:00 ` [PATCH v2 4/9] mm/huge_memory: handle buggy PMD entry in zap_huge_pmd() Lorenzo Stoakes (Oracle)
2026-03-20 3:20 ` Baolin Wang
2026-03-19 13:00 ` [PATCH v2 5/9] mm/huge_memory: add a common exit path to zap_huge_pmd() Lorenzo Stoakes (Oracle)
2026-03-20 3:27 ` Baolin Wang
2026-03-19 13:00 ` [PATCH v2 6/9] mm/huge_memory: remove unnecessary VM_BUG_ON_PAGE() Lorenzo Stoakes (Oracle)
2026-03-20 3:31 ` Baolin Wang
2026-03-19 13:00 ` [PATCH v2 7/9] mm/huge_memory: deduplicate zap deposited table call Lorenzo Stoakes (Oracle)
2026-03-19 17:03 ` Kiryl Shutsemau
2026-03-19 17:18 ` Lorenzo Stoakes (Oracle)
2026-03-19 21:56 ` Kiryl Shutsemau
2026-03-20 13:59 ` Lorenzo Stoakes (Oracle)
2026-03-20 14:14 ` Lorenzo Stoakes (Oracle)
2026-03-19 13:00 ` [PATCH v2 8/9] mm/huge_memory: deduplicate zap_huge_pmd() further by tracking state Lorenzo Stoakes (Oracle)
2026-03-20 3:49 ` Baolin Wang [this message]
2026-03-20 13:51 ` Lorenzo Stoakes (Oracle)
2026-03-21 5:15 ` Baolin Wang
2026-03-19 13:00 ` [PATCH v2 9/9] mm/huge_memory: have zap_huge_pmd() use vm_normal_folio_pmd() Lorenzo Stoakes (Oracle)
2026-03-20 3:09 ` [PATCH v2 0/9] mm/huge_memory: refactor zap_huge_pmd() Andrew Morton
2026-03-20 13:27 ` Lorenzo Stoakes (Oracle)
2026-03-21 3:21 ` Roman Gushchin
2026-03-21 3:33 ` Andrew Morton
2026-03-22 0:15 ` Andrew Morton
2026-03-22 2:12 ` Roman Gushchin
2026-03-23 11:19 ` Lorenzo Stoakes (Oracle)
2026-03-23 11:24 ` David Hildenbrand (Arm)
2026-03-23 11:31 ` Lorenzo Stoakes (Oracle)
2026-03-23 12:34 ` Pedro Falcato
2026-03-23 21:36 ` Andrew Morton
2026-03-23 23:27 ` Pedro Falcato
2026-03-24 0:05 ` Andrew Morton
2026-03-24 7:35 ` Lorenzo Stoakes (Oracle)
2026-03-24 7:58 ` Mike Rapoport
2026-03-24 9:55 ` Lorenzo Stoakes (Oracle)
2026-03-24 1:08 ` Roman Gushchin
2026-03-24 7:56 ` Lorenzo Stoakes (Oracle)
2026-03-24 15:24 ` Roman Gushchin
2026-03-24 18:05 ` Lorenzo Stoakes (Oracle)
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=d67ff262-a627-4cd3-b126-dd82eb8d3412@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=npache@redhat.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=ziy@nvidia.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