Re: [PATCH 1/1] mm/huge_memory: fix pgtable withdrawal for huge zero PMDs

[Lance Yang]

On 2026/9/16 14:11, David Hildenbrand (Arm) wrote:
> On 9/16/26 06:41, Lance Yang wrote:
> > On Tue, Sep 15, 2026 at 05:13:17PM +0200, David Hildenbrand (Arm) wrote:
> > [...]
> > > Ok, it's really only DAX and anonymous VMAs that use the huge zero folio. Other
> > > (module) code would have a hard time using it, as mm_get_huge_zero_folio() is
> > > not exported to modules.
> > >
> > > DAX uses dax_pmd_load_hole()->vmf_insert_folio_pmd()->insert_pmd() where we
> > > deposit a page table only if arch_needs_pgtable_deposit().
> > >
> > >
> > > So I think the rule is simply:
> > >
> > > arch_needs_pgtable_deposit() -> always deposited
> > > vma_is_anonymous() -> always deposited
> > >
> > > ?
> >
> > YES!
> >
> > > The trick is that we don't have anon THPs in non-anon VMAs.
> > >
> > > So could this be simplified further or am I missing something?
> >
> > Ah, cool! I hadn't thought of that :) You're right, anon THPs cannot live
> > in non-anon VMAs, so pmdval and folio aren't needed here. Will simplify
> > it as suggested :) and add a comment explaining the rule.
> >
> > static bool has_deposited_pgtable(struct vm_area_struct *vma)
> > {
> > 	return arch_needs_pgtable_deposit() || vma_is_anonymous(vma);
> > }
>
> Yes, that's what I had in mind. (while at it, maybe call it "vma_has_*)

Good point, will do. Thanks!