Message-ID: <57cffedc-65c0-44f1-8364-3a3ff9bdc760@lucifer.local>
Date: Tue, 14 Oct 2025 16:52:38 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Lance Yang <lance.yang@...ux.dev>, akpm@...ux-foundation.org,
        Liam.Howlett@...cle.com, baohua@...nel.org,
        baolin.wang@...ux.alibaba.com, dev.jain@....com, hughd@...gle.com,
        ioworker0@...il.com, kirill@...temov.name,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org, mpenttil@...hat.com,
        npache@...hat.com, ryan.roberts@....com, ziy@...dia.com,
        richard.weiyang@...il.com
Subject: Re: [PATCH mm-new v3 1/1] mm/khugepaged: abort collapse scan on
 non-swap entries

On Tue, Oct 14, 2025 at 05:11:12PM +0200, David Hildenbrand wrote:
> On 14.10.25 16:39, Lorenzo Stoakes wrote:
> > On Tue, Oct 14, 2025 at 10:26:20PM +0800, Lance Yang wrote:
> > >
> > >
> > > On 2025/10/14 19:08, Lorenzo Stoakes wrote:
> > > > On Wed, Oct 08, 2025 at 11:26:57AM +0800, Lance Yang wrote:
> > > > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > > > index abe54f0043c7..bec3e268dc76 100644
> > > > > --- a/mm/khugepaged.c
> > > > > +++ b/mm/khugepaged.c
> > > > > @@ -1020,6 +1020,11 @@ static int __collapse_huge_page_swapin(struct mm_struct *mm,
> > > > >    		if (!is_swap_pte(vmf.orig_pte))
> > > > >    			continue;
> > > > >
> > > > > +		if (non_swap_entry(pte_to_swp_entry(vmf.orig_pte))) {
> > > > > +			result = SCAN_PTE_NON_PRESENT;
> > > > > +			goto out;
> > > > > +		}
> > > >
> > > > OK seems in line with what we were discussing before...
> > >
> > > Yep. That's the idea :)
> > >
> > > >
> > > > > +
> > > > >    		vmf.pte = pte;
> > > > >    		vmf.ptl = ptl;
> > > > >    		ret = do_swap_page(&vmf);
> > > > > @@ -1281,7 +1286,23 @@ static int hpage_collapse_scan_pmd(struct mm_struct *mm,
> > > > >    	for (addr = start_addr, _pte = pte; _pte < pte + HPAGE_PMD_NR;
> > > > >    	     _pte++, addr += PAGE_SIZE) {
> > > > >    		pte_t pteval = ptep_get(_pte);
> > > > > -		if (is_swap_pte(pteval)) {
> > > > > +		if (pte_none(pteval) || is_zero_pfn(pte_pfn(pteval))) {
> > > > > +			++none_or_zero;
> > > > > +			if (!userfaultfd_armed(vma) &&
> > > > > +			    (!cc->is_khugepaged ||
> > > > > +			     none_or_zero <= khugepaged_max_ptes_none)) {
> > > > > +				continue;
> > > > > +			} else {
> > > > > +				result = SCAN_EXCEED_NONE_PTE;
> > > > > +				count_vm_event(THP_SCAN_EXCEED_NONE_PTE);
> > > > > +				goto out_unmap;
> > > > > +			}
> > > > > +		} else if (!pte_present(pteval)) {
> > > > > +			if (non_swap_entry(pte_to_swp_entry(pteval))) {
> > > >
> > >
> > > Thanks for pointing that out!
> >
> > You've deleted what I've said here and also not indicated whether you'll do what
> > I asked :)
> >
> > Please be clearer...
> >
> > >
> > > > Hm but can't this be pte_protnone() at this stage (or something else)? And then
> > >
> > > Yeah. The funny thing is, a protnone pte cannot actually get here, IIUC.
> > >
> > > ```
> > > static inline int pte_protnone(pte_t pte)
> > > {
> > > 	return (pte_flags(pte) & (_PAGE_PROTNONE | _PAGE_PRESENT))
> > > 		== _PAGE_PROTNONE;
> > > }
> > >
> > > static inline int pte_present(pte_t a)
> > > {
> > > 	return pte_flags(a) & (_PAGE_PRESENT | _PAGE_PROTNONE);
> > > }
> > > ```
> > >
> > > On x86, pte_present() returns true for a protnone pte. And I'd assume
> > > other archs behave similarly ...
> >
> > This was one example, we may make changes in the future that result in entries
> > that are non-present but also non-swap.
> >
> > I don't see the point in eliminating this check based on an implicit, open-coded
> > assumption that this can never be the case, this is just asking for trouble.
> >
> > >
> > > > we're just assuming pte_to_swp_entry() is operating on a swap entry when it in
> > > > fact might not be?
> > > >
> > > > Couldn't we end up with false positives here?
> > >
> > > Emm, I think we're good here and the code is doing the right thing.
> >
> > I mean sorry but just - NO - to doing swap operations based on open-coded checks
> > that you implicitly feel must imply a swap entry.
> >
> > This makes the code a lot more confusing, it opens us up to accidentally
> > breaking things in future and has little to no benefit, I don't see why we're
> > doing it.
> >
> > I don't think every little 'aha X must imply Y so just eliminate Z' idea need be
> > implemented, this feels like a sort of 'mathematical reduction of code ignoring
> > all other factors'.
>
> Not sure I follow. If something is !none && !present it's what we call a
> swap PTE (that includes actual swap and non-swap PTEs).

You see this is the issue. You know that. I knew that, then forgot that :)

Obviously you can go read the function:

/* check whether a pte points to a swap entry */
static inline int is_swap_pte(pte_t pte)
{
	return !pte_none(pte) && !pte_present(pte);
}

And see that this is the definition.

You also have to know that we hack pte_present() so it doesn't actually tell you
the whether the PTE is present but whether it's present and _not protnone_ and
again, I just forgot :>)

But that's the point! You shouldn't _need_ to 'just know' these things.

We have some operations that _require_ the entry to be a swap entry (including
the very poorly named 'non swap entry'), or they'll read back/write garbage.

My key arugment is:

	if (is_thing_we_want())
		do_stuff_with_thing();

Abstracts all this, and is far better than:

	if (condition_a) {
		...
	} else if (!condition_b) {
		do_stuff_with_thing(); // you should just know that !a, !b means we can.
	}

I do agree that the naming is very bad here.

>
> We have the exact same code flow for example in
> copy_pte_range()->copy_nonpresent_pte() and I don't see a problem with it.

Obviously I'd make the same argument above.

>
> If we were to ever change what we call a "swap PTE" (I don't think so?) we'd
> have to fix stuff all over the place.

Sorry it's my mistake for raising this point about some imagined new non-present
PTE that is also not-none, I'm fresh off vacation and forgetting things clearly
:)

So withdraw that point.

>
> Maybe I get the concern here wrong?
>
> --
> Cheers
>
> David / dhildenb
>

Perhaps the naming is really the issue...

Cheers, Lorenzo

Powered by blists - more mailing lists