Re: [PATCH mm-new v6 2/5] mm: khugepaged: refine scan progress number

From: Vernon Yang

Date: Thu Feb 05 2026 - 01:10:45 EST


On Thu, Feb 5, 2026 at 5:35 AM David Hildenbrand (arm) <david@xxxxxxxxxx> wrote:
>
> [...]
>
> > + if (cur_progress) {
> > + if (_pte >= pte + HPAGE_PMD_NR)
> > + *cur_progress = HPAGE_PMD_NR;
> > + else
> > + *cur_progress = _pte - pte + 1;
>
> *cur_progress = max(_pte - pte + 1, HPAGE_PMD_NR);

I guess, your meaning is "min(_pte - pte + 1, HPAGE_PMD_NR)", not max().

> ?
>
> It's still a bit nasty, though.
>
> Can't we just add one at the beginning of the loop and let the compiler
> optimize that? ;)

I'm also worried that the compiler can't optimize this since the body of
the loop is complex, as with Dev's opinion [1].

[1] https://lore.kernel.org/linux-mm/7c4b5933-7bbd-4ad7-baef-830304a09485@xxxxxxx

If you have a strong recommendation for this, please let me know, Thanks!

> > + }
> > pte_unmap_unlock(pte, ptl);
> > if (result == SCAN_SUCCEED) {
> > result = collapse_huge_page(mm, start_addr, referenced,
> > @@ -2286,8 +2301,9 @@ static enum scan_result collapse_file(struct mm_struct *mm, unsigned long addr,
> > return result;
> > }
> >
> > -static enum scan_result hpage_collapse_scan_file(struct mm_struct *mm, unsigned long addr,
> > - struct file *file, pgoff_t start, struct collapse_control *cc)
> > +static enum scan_result hpage_collapse_scan_file(struct mm_struct *mm,
> > + unsigned long addr, struct file *file, pgoff_t start,
> > + unsigned int *cur_progress, struct collapse_control *cc)
> > {
> > struct folio *folio = NULL;
> > struct address_space *mapping = file->f_mapping;
> > @@ -2376,6 +2392,8 @@ static enum scan_result hpage_collapse_scan_file(struct mm_struct *mm, unsigned
> > cond_resched_rcu();
> > }
> > }
> > + if (cur_progress)
> > + *cur_progress = max(xas.xa_index - start, 1UL);
> I would really just keep it simple here and do a
>
> *cur_progress = HPAGE_PMD_NR;
>
> This stuff is hard to reason about, so I would just leave the file case
> essentially unchanged.
>
> IIRC, it would not affect the numbers you report in the patch description?

Yes, Let's keep it simple, always equal to HPAGE_PMD_NR in file case.

--
Thanks,
Vernon