linux-kernel - Re: [RFC PATCH] mm: huge_memory: add folio_mark

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250408160205.GD816@cmpxchg.org>
Date: Tue, 8 Apr 2025 12:02:05 -0400
From: Johannes Weiner <hannes@...xchg.org>
To: Zi Yan <ziy@...dia.com>
Cc: Baolin Wang <baolin.wang@...ux.alibaba.com>, akpm@...ux-foundation.org,
	willy@...radead.org, david@...hat.com, 21cnbao@...il.com,
	ryan.roberts@....com, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] mm: huge_memory: add folio_mark_accessed() when
 zapping file THP

On Tue, Apr 08, 2025 at 11:29:43AM -0400, Zi Yan wrote:
> On 8 Apr 2025, at 9:16, Baolin Wang wrote:
> 
> > When investigating performance issues during file folio unmap, I noticed some
> > behavioral differences in handling non-PMD-sized folios and PMD-sized folios.
> > For non-PMD-sized file folios, it will call folio_mark_accessed() to mark the
> > folio as having seen activity, but this is not done for PMD-sized folios.
> >
> > This might not cause obvious issues, but a potential problem could be that,
> > it might lead to more frequent refaults of PMD-sized file folios under memory
> > pressure. Therefore, I am unsure whether the folio_mark_accessed() should be

Acked-by: Johannes Weiner <hannes@...xchg.org>

> How likely will the system get PMD-sized file folios when it is under
> memory pressure? Johannes’ recent patch increases THP allocation successful
> rate, maybe it was not happening before but will be after the patch?

It's not so much about whether the refault can construct a THP again,
but whether we should have evicted this data under pressure to begin
with. It's more about IO and paging. And it's the same consideration
why we transfer the young bit for base pages.

Sometimes file contents are only accessed through relatively
short-lived mappings. But they can nevertheless be accessed a lot and
be hot. It's important to not lose that information on unmap, and end
up kicking out a frequently used cache page.

> > added for PMD-sized file folios?
> 
> Do you see any performance change after your patch?
> 
> >
> > Signed-off-by: Baolin Wang <baolin.wang@...ux.alibaba.com>
> > ---
> >  mm/huge_memory.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 6ac6d468af0d..b3ade7ac5bbf 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -2262,6 +2262,10 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> >  				zap_deposited_table(tlb->mm, pmd);
> >  			add_mm_counter(tlb->mm, mm_counter_file(folio),
> >  				       -HPAGE_PMD_NR);
> > +
> > +			if (flush_needed && pmd_young(orig_pmd) &&
> > +			    likely(vma_has_recency(vma)))
> > +				folio_mark_accessed(folio);
> >  		}
> >
> >  		spin_unlock(ptl);
> > -- 
> > 2.43.5